Anotações Banco de Dados

- Os conceitos de banco de dados e modelo entidade relacionamento: O banco de daos
surgiu da necessidade de guardar informações

em meio eletrônico para substituir os arquivos em papeis e por ser mais rápido na
recuperação dos dados.
Nos idos dos anos 1960, surgiram os primeiros bancos de dados. A IBM lançou um tipo
de banco de dados para os computadores
mainframe, chamado de IMS (Information Management System), um banco de dados em
disco rígido, com acesso hierárquico para
atender a NASA no projeto espacial Apolo.
De lá para cá, surgiram vários tipos de armazenamentos de bancos de dados para
microcomputadores, unidades de fitas, disquetes, etc.
Um funcionário da IBM, em 1970, o Sr. Edgar Frank Codd, idealizou e lançou o
primeiro banco de dados relacional. Todos os bancos de
dados relacionais trabalham com o padrão ANSI – SQL.
Existem vários SBDS, operando no mercado de Tecnologia da Informação, os mais
destacados são: ORACLE, da ORACLE; DB2, da IBM;
Sybase, da SAP; MYSQL, da ORACLE; POSTEGRE, patrocinados por um consórcio de
patrocinadores: Redpill Linpro, PGX, EBC, etc.
- Estrutura de um sistema gerenciador de banco de dados (SGBD):

as aplicações estão relacionadas ao Client (Clientes) e o servidor (SGBD) exerce o
papel de fazer a comunicação entre a aplicação e o
banco de dados.
Os bancos de dados possuem um gerenciamento complexo. Gerenciam a sintaxe de
comandos DDL e DML, gerenciam a priorização de
demandas, disponibilizam relatórios para acompanhar os indicadores de desempenho e
de situações de erros. O SGBD exerce controle
sobre paradas e retomadas de processamento, tem um controle de ponteiros de
processamento preciso.
Os SGBDs também geram relatórios com indicadores gráficos em que são fáceis de
entender alguma anormalidade ocorrida. Têm
interface com planilhas eletrônicas para gerar as tabelas no formato de planilha,
processam linguagem de alto nível com o SQL, interagem
com todas as linguagens de programação do mercado: Java, VB, Cobol, .NET, Python,
PHP, etc. Possuem mecanismos de backups
automáticos e programados, possibilitam a “importação” e a “extração” de bancos de
dados, não importando o volume de dados. Possuem
rotinas para reorganização automática dos índices de todas as tabelas, possibilitam
integração de banco de dados distribuídos, suportam
altos volumes de dados com desempenho estável e confiável. Possibilitam integração
com ferramentas case externas para modelagem de
dados e possuem também ferramenta case nativa para modelagem de dados.
O Servidor é o próprio SGBD. Compreende definições de dados; manipulação de dados,
segurança e integridade de dados. Os Clientes
são aplicações executadas sobre o SGBD.
O SGBD concilia e viabiliza o pedido externo (usuário) e interno (SGBD) e a
estrutura de armazenamento; executa operações sobre banco
de dados armazenados, aceita definições de dados: esquemas externo, conceitual,
interno e mapeamentos, e converte para objeto
executáveis, inclui processadores ou compilações de DDL – linguagem de definição de
dados –, denominados scripts de criação dos
bancos de dados, processa ou compila DML (linguagem de manipulação de dados).
DML planejada é o estudo prévio da solicitação. O programador idealiza a função a
ser executada em banco de dados, e simula em
ferramentas de editores de Bancos de Dados ou Editores de Linguagens de
Programação, e com a execução dos comandos de Bancos de
Dados (SQL) verifica se o resultado atende a necessidade do programador.
DML não planejada, ad hoc, pode incorrer em inviabilidade na operação do banco de
dados. São provenientes de execução de comandos
por tentativa e erro, ocorre de forma direta e interativa, em ferramentas que
possibilitam o acesso a banco de dados, por exemplo, editores
de Banco de Dados, IDE (workbench) do ORACLE; IDE (workbench) do MYSQL; IDE
(workbench) Postgree. Com isso, há um ganho de
otimização do SGBD. Além disso, há como prevenir que situações que venham a
comprometer a segurança e a integridade dos dados
também restringem as regras de incorretas nos acessos para recuperação e
concorrência dos dados.
O SGBD tem um dicionário de dados que compreende os nomes dos atributos
(metadados), também guarda todas as informações de
parâmetros dos bancos criados, nomes dos bancos, nomes das tabelas, nomes de
índices, restrições de acessos.
O Modelo Relacional, apresenta os elementos que envolvem a estrutura de dados,
reflete quais são os componentes que compõem a
integridade de dados e a manipulação de dados.
.RELAÇÃO: Corresponde a tabela como um todo. é o conjunto de atributos, tamanho dos
atributos, indice da tabela, dados cadastrados e a
quantidades de linhas.
.TUPLA: Corresponde a cada linha da tabela(registros), com dados
cadastrados(populados).
.ATRIBUTO: Corresponde as caracteristicas de ome, tamanho de cada coluna da
tabela(campos). os nomes servem de referencia para
os aplicativos obterem ou atualizarem os dados respectivos aos atributos.
.CARDINALIDADE: Corresponde a quantidade de tuplas, ou seja, ao numero de linhas
cadastradas na tabela.
.PREDICADO: Corresponde ao relacionamento de afinidade entre os atributos.
.CORPO: Corresponde ao cabeçalho da tabela, que identifica cada atributo da tabela.
.DEADLOCK: A situação na qual duas ou mais transações disputam a atualização da
mesma tupla, uma espera a outra e aguarda a
liberação de desbloqueio.
Imterromper um DEADLOCK envolve a escolha de uma transação ROLLBACK, liberando o
bloqueio, permitindo assim o prosseguimento
da transação que esteja aguardando.
-Conceitos de modelagem de banco de dados:

A técnica de normalização abrange uma análise dos dados brutos. a primeira ação é
separar os dados em conjuntos de dados com os
mesmos objetivos e afinidades, e ainda idealizar um conjunto de dados sem
redundância. Devido a essa duplicidade, torna-se necessário
aplicar uma técnica de normalização para eliminar a duplicidade. A duplicidade no
jargão da modelagem de dados é considerada como
redundância. Com isso, haverá uma vantagem, pois na necessidade de se obter somente
o nome do cliente podemos acessar somente
uma vez. Com isso, diminui-se a quantidade de acessos, tendo um ganho de desempenho
na velocidade do SGBD. Ainda se ganha ao
evitar o armazenamento desnecessário, devido à duplicidade do nome do cliente, pois
o nome do cliente é o campo em que, normalmente,
há uma necessidade de tamanho de 30 a 40 caracteres. Teríamos uma economia de 30
caracteres.
-Conceitos e notações gráficas:

É preciso entender algumas regras de associações entre tuplas (classes).
Basicamente, temos as seguintes situações:
● Associação - é um relacionamento estrutural que especifica que objetos de um
elemento estão conectados a objetos de outro elemento.
● Agregação - relacionamento fraco do tipo “é parte de”. É um tipo especial de
associação.
● Composição - relacionamento forte do tipo “é parte de”. A composição entre um
elemento (o “todo”) e outros elementos (“as partes”)
indica que as partes só existem em função do “todo”.
● Dependência - Uma dependência entre classes indica que os objetos de uma classe
usam serviços dos objetos de outra classe.
● Generalização (herança) - Relacionamento entre um elemento mais geral (chamado de
superclasse ou pai) e um mais específico
(chamado de subclasse ou filho).
● Realização - relacionamento entre uma interface e o elemento que a implementa.
Herança ou Dependências de relações entre tuplas (Classes)
Uma dependência indica que alguma mudança em um elemento podem refletir em outro
elemento, com isso temos restrições de
atualizações entre classes. Uma dependência entre classes indica que os objetos de
uma classe usam serviços dos objetos de outra classe.
Relacionamento entre um elemento mais geral (chamado de superclasse ou pai) e um
mais específico (chamado de subclasse ou filho).
O gerenciar de banco de dados exerce um controle de restrição, por exemplo, no caso
de exclusão.
Primeiro há de se excluir os filhos, após isso é que é permitida a exclusão do pai.
Esta restrição é chamada de Constrain.
A classe forma pode ter várias representações: um retângulo, um círculo ou um
polígono, que herdam as informações da forma; e o
quadrado herda as informações da forma e do retângulo. Com isso, por meio da
herança, evita-se duplicar informações e funções para as
classes que forem necessárias. Outro exemplo de superclasses, conforme a figura 6:
podemos ter veículos terrestre ou aquático, e podemos
ter uma classe que reúne as informações e funções dos veículos aquático e
terrestre; temos uma classe anfíbio.
A Cardinalidade diz respeito a uma técnica de como uma classe é dependente da outra
em relação – considerando os conteúdos de cada
classe. Conforme ilustra a figura 7, pode-se explicar em várias representações
gráficas, imaginando que tenhamos duas classes para
comparar. No primeiro caso, temos uma classe que corresponde a somente uma classe
associada, com a indicação do número “1”.
Exemplo: a classe CPF ocorre somente uma vez com a classe RG. No segundo caso, a
indicação de “*” significa que temos; de um lado,
uma classe com uma ocorrência; e do outro lado, uma classe que tem várias
ocorrências. Exemplo: a classe CPF tem uma ocorrência e
na classe endereço podemos ter mais de uma ocorrência: um endereço residencial, um
endereço comercial e um endereço de contato.
No terceiro caso, a indicação de “1..0” significa que em uma classe com essa
indicação podemos ter uma ocorrência ou ter uma classe
sem nenhum dado. No quarto caso, a indicação de “m..n” significa que podemos ter
ocorrência fixa de intervalo, por exemplo 1..5; nesse
caso, podemos ter uma linha (registro) e no máximo 5 linhas (registros).
2003.
Quando há duas classes envolvidas na associação de forma direta, de uma para a
outra (conforme figura 8), traduzindo a representação,
significa que um número de Cliente pode ter nenhum pedido “0” ou ter vários números
de pedidos “*”, enquanto que um número de pedido
só pode ser de um cliente.
-Autorrelacionamento: Há situações diferenciadas que são do autorrelacionamento, em
que o empregado exerce mais de um papel:
ora é empregado ora é chefe.
-Modelagem de banco de dados - Normalização:

O relacionamento considerado associativo corresponde a criar uma nova classe, que é
chamada de associativa. Compõe-se, basicamente,
de chaves estrangeiras (Foreign Key – FK) mais os dados redundantes de chave
própria da classe Movimentação da Conta
(tipo de lançamento e data do lançamento), redundância, e ainda de mais um dado que
não é chave, é o valor do lançamento. Nesse caso
temos que um Cliente tem várias movimentações e que uma Conta Corrente tem várias
movimentações.
Toda vez que há chave estrangeira (FK), existe uma restrição. Para excluir qualquer
linha (registro) da tabela movimentação Conta, é preciso
antes excluir a linha (registro) do Cliente e também, antes, deve-se excluir a
linha (registro) da Conta Corrente. Se não for efetuado dessa
forma, o gerenciador de Banco de Dados (SGBD) barra a exclusão da tabela
Movimentação Conta. A chave estrangeira possui esse nome
porque a chave da Movimentação da Conta é proveniente do Código da classe Cliente
(FK). A chave estrangeira Código da conta é
proveniente da classe Conta Corrente. Observe que, para atribuir nome às
informações do banco de dados, evitamos todo o tipo de
acentuação, caracteres especiais. A tabela Movimentação Conta está na 3 FN. Como
pode ser observado a seguir, normalmente se
considera esta tabela como dados históricos. Considera-se esta tabela com uma
cardinalidade de N (*) para N (*).
relacionamento Associativo. Fonte: Elaboração própria.
Uma forma especial de associação entre o todo e suas partes, na qual o todo é
composto de partes, é a agregação.
Não impõe que a vida das “Partes” esteja relacionada com a vida do “Todo”, ou seja,
se decidirmos excluir algum elemento, isso não
interfere no funcionamento do todo, que é o computador.
A composição é parecida com a agregação, e se diferencia nos seguintes aspectos:
Todos os elementos compõem o todo, e a falta de um
só elemento inviabiliza o todo.
- Técnicas de criação de índices:
O acesso por índice influi para o SGBD operar com mais rapidez para buscar
informações em uma tabela (arquivo). Para a informação
servir de índice, tem de ser única; deve ter somente uma ocorrência em toda a
tabela.
A informação de índice deve ser do tipo numérica; raramente será do tipo
alfanumérica. O índice alfanumérico demora mais para o SGBD
converter byte a byte para o binário, que é o formato utilizado pelo SGBD para
acessar a tabela. O campo textual normalmente tem tamanho
não recomendável. O índice pode envolver somente uma informação, considerado chave
simples; ou pode envolver mais de uma
informação, considerado chave composta. Quando não é possível ter uma informação
como chave única na tabela, precisamos elencar
mais uma informação para termos outra informação como chave única.
Todas as informações de índices devem estar nos primeiros campos da tabela, jamais
devem ficar no meio ou no fim da tabela.
As informações para índices não devem ser nulas.
-Modelagem de banco de dados - Conceitos de formas normais:

O relacionamento entre as classes em que há uma forma de dependência tem uma
técnica que faz parte da normalização e ajuda no
entendimento nas análises das dependências.
- 1 forma normal (1FN): Cada informação deve ter atributos atômicos; só deve
permitir atributos atômicos (simples, indivisíveis).
Essa forma contém anomalias: o telefone da agência é multivalorado, pois podemos
ter vários números de telefones. Isso dificulta para
incluir, alterar ou excluir um telefone da agência.
CONTRATO {id_contrato, id_pacote, preco_pacote, cnpj_agencia, nome_agencia,
telefone_agencia, rg_cliente, nome_cliente }
CONTRATO {id_contrato, id_pacote, preco_pacote, #id_agencia, rg_cliente,
nome_cliente }
AGENCIA {Id_agencia, cnpj_agencia, nome_agencia, telefone_agencia}
Dados sem normalização
Solução 1FN: devemos separar os dados do telefone da agência, criando uma nova
relação chamada AGENCIA, criando um dado artificial
como chave única = id_agencia.
- 2 forma normal (2FN): Uma tabela está na 2FN se, e somente se, ela estiver na 1FN
e não possuir Dependência Funcional Parcial (DF).
Nessa forma, os atributos que não são chaves devem conter informações que se
referem à chave inteira, e não somente a parte do registro.
Nesta 2FN, o registro CONTRATO foi dividido em duas novas relações, incluindo
informações separadas sobre a agência e sobre o cliente.
Nesta 2FN ainda podem ocorrer anomalias de atualização e exclusão, por exemplo, em
alterações de dados sobre o pacote.
CONTRATO {# id_contrato, id_pacote, preco_pacote, #id_agencia, rg_cliente, }
AGENCIA { # Id_agencia, cnpj_agencia, nome_agencia, telefone_agencia}
CLIENTE {# rg-cliente, nome_cliente}
- 3 forma normal (3FN): Uma tabela está na 3FN se, e somente se, ela estiver na 2FN
e não possuir DFs indiretas. Tabelas com
Dependências Funcionais indiretas devem ser desmembradas em tabelas que não possuem
tais dependências funcionais.
Esta 3FN refere-se ao agrupamento de relações requeridas na 2FN e, para resolver a
anomalia da 2FN, com relação a pacote, criamos
mais uma relação chamada PACOTE. Quando se chega neste nível, podemos afirmar que
não há mais dados redundantes e os índices
criados ajudam no bom desempenho de acesso às tabelas. Com isso, o banco de dados
se torna flexível para suportar qualquer alteração
no “front end” (Telas de entradas e saídas de dados). Quando chegamos à terceira
forma normal, eliminamos a redundância de atributos.
Por exemplo, para todos os contratos teríamos duplicado o nome do cliente. Além
disso, temos uma distribuição das informações de forma
organizada, com a criação de atributos chaves de forma coerente e, quando
precisamos acessar somente dados do cliente, fica mais
simples; não há dados desnecessários – da agência, por exemplo.
CONTRATO {# id_contrato, id_pacote, #id_agencia, rg_cliente, }
AGENCIA {# Id_agencia, cnpj_agencia, nome_agencia, telefone_agencia}
CLIENTE {# rg-cliente, nome_cliente}
PACOTE { # id_pacote, preco_pacote }
-Diagrama de entidade e relacionamento (DER) - Ferramenta case - Software Livre:

A ferramenta Case serve para desenhar um Banco de Dados lógico. Recomendamos
utilizar o software livre da DBDesignerfork, que é uma
ferramenta amigável e de facilidade visual para o Windows. É uma ferramenta IDE
(Ambiente de Desenvolvimento Integrado; não é
necessário instalar, pode ser executado como um software interpretado, pode ser
baixado,
no seguinte link: https://db-designer-fork.soft112.com.
Após baixado, extrair para um diretório de sua preferência.
Para executar o software, dar duplo clique no arquivo DBDesignerfork.exe.
-MODELO LÓGICO E PROJETO FÍSICO DE BANCO DE DADOS:

Para se construir um banco de dados bem estruturado, há uma técnica chamada de
modelagem de dados, em que se analisam as regras de
negócio de forma científica – isso ajuda os técnicos de informática a entenderem a
necessidade dos usuários.
A modelagem de dados é um trabalho exaustivo para distribuir as informações em
conjuntos de informações que atendam ao melhor
desempenho no tempo de resposta, que se adeque aos requisitos da inteligência do
sistema: em termos de protótipo de telas, em termos da
facilidade operacional para o usuário, em termos de suportar as manutenções
necessárias ao longo do ciclo de vida do sistema. Ainda, que se
enquadre tecnicamente nas regras de modelagem de banco de dados.
Por exemplo, o quanto uma tabela (conjuntos de informações pertinentes a um
assunto) está relacionada à outra; relacionamento das tabelas,
o quanto uma informação é dependente da outra; qual a forma de acesso por índices
de cada tabela. Tudo isso é pensando e idealizado por um
analista de sistemas, que primeiro passa por aprovação de um Administrador de Dados
(AD). Após isso, a criação do banco de dados passa
para um Administrador de Banco de Dados (DBA), que realiza a criação de banco de
dados por meio de um gerenciador de banco de dados
(SGBD).
O momento de concepção de uma modelagem de dados é conhecido como projeto lógico,
em que se gera uma documentação com
simbologia gráfica, a qual os técnicos em tecnologia da informação entendem como
uma comunicação universal. Isso facilita para o técnico
compreender a lógica dos bancos de dados, mesmo que não tenham sido idealizados por
ele.
A criação dos bancos de dados num gerenciador de banco de dados (SGBD) é conhecida
como projeto físico.
-PROJETOS CONCEITUAL X LÓGICO X FÍSICO:

Não só é esclarecido o que contém cada fase do projeto, mas explicam-se os
conceitos e técnicas de como elaborar uma modelagem de dados
e em qual momento e o que determina a passagem de um projeto para outro.
ENTENDIMENTO DO PROJETO CONCEITUAL:
O projeto conceitual compreende uma fase em que o técnico de tecnologia da
informação passa por imersão para entendimento dos detalhes
das necessidades do usuário, analisa cenários de processos, analisa volumes das
informações, analisa os requisitos funcionais das regras de
negócios e não funcionais, que envolvem necessidades para acesso e atualização de
dados.
Após o técnico (Analista de Sistemas/Programador) estar seguro do entendimento de
todas as nuances que envolvem as regras de negócios,
ele parte para modelar os bancos de dados e entra na fase de projeto lógico.
ENTENDIMENTO DO PROJETO LÓGICO:
O projeto lógico é uma conversão da regra de negócio em um modelo gráfico – em que
podemos usar ferramenta Case, que gera este artefato
gráfico.
Conforme mencionado anteriormente, esse artefato é chamado de Diagrama de Entidade
e Relacionamento (DER) ou de Modelo de Entidade
e Relacionamento (MER), as duas referências referem-se ao mesmo artefato.
Vamos estudar de forma mais detalhada as técnicas que envolvem a modelagem de
dados.
CONCEITOS DE METODOLOGIA ORIENTADA A OBJETOS:
Todas as metodologias de desenvolvimento de sistemas – seja a estruturada,
orientada a objetos, ágil – têm a necessidade de modelagem de
dados. A orientada a objetos tem alguns conceitos complementares que integram com a
modelagem de dados. Dentre esses conceitos é
interessante entender alguns pontos básicos.
a) CLASSE – Abstração de um conjunto de objetos similares aos do mundo real. O
livro tem características (tamanho, tipo) mostradas nos objetos.
b) OBJETO – Qualquer coisa do mudo real ou abstrata, que tem tamanho e tipo. O
objeto é subdivisão da classe; pode ocorrer termos de uma
classe que não tem objetos, portanto, a classe é o próprio objeto, pois a estrutura
da classe e objeto, tem a mesma estrutura com tamanho e tipo.
c) Relação de Classe com Objeto – Todo objeto é uma instância de uma Classe. Todas
as instâncias de uma classe têm valores próprios para
os atributos especificados na classe. Os objetos são representados por determinada
classe e diferenciam-se entre si pelos valores de seus
atributos.
ENTIDADES X ATRIBUTOS X RELACIONAMENTO:
Existem três formas básicas para trabalhar a modelagem de dados: uma é chamada de
entidade e faz referência a algum objeto do mundo real,
concreto, por exemplo, uma pessoa; ou abstrato, por exemplo, um departamento. Outra
é chamada de atributo, que detalha cada informação
relacionada às entidades. E a terceira forma, sobre o relacionamento de
dependências entre as entidades ou entre os atributos.
A modelagem é uma engenharia de dados, que exige muita paciência, coerência, bom
senso, conhecimento de todas as técnicas de
modelagem, entender o objetivo e o sentido de cada informação. Juntando tudo isso,
é preciso trabalhar exaustivamente, com muita atenção e
concentração para alcançar um resultado de sucesso.
ENTIDADES:
É um conjunto de objetos do mundo real sobre os quais se deseja manter informações
no banco de dados.
É retratado pelo desenho de um retângulo e pode representar objetos concretos (um
empregado), Citamos alguns conteúdos possíveis,
chamados de instâncias: João, Pedro, Paulo e Maria.
Um outro exemplo é para os objetos abstratos (um departamento), Citar conteúdos
possíveis: Contabilidade, Financeiro, Jurídico e Pessoal.
ATRIBUTOS:
Atributo é um dado, corresponde a cada informação que compõe a entidade. Para cada
atributo é necessário identificar duas informações;
dessas duas, uma é referente à quantidade que comporta o conteúdo do atributo; a
outra é referente ao tipo do dado, que pode ser numérico ou
alfanumérico. O Atributo também pode estar associado ao relacionamento.
Em um DER, uma entidade é representada por meio de um retângulo que contém o nome
da entidade. O relacionamento é representado por
um losango e, dentro dele, vai o nome do relacionamento.
Os atributos, são representados por um traço mais um círculo. Quando o círculo
estiver preenchido, identifica um atributo chave; e quando o
círculo estiver vazio, identifica um atributo não chave.
RELACIONAMENTOS:
O relacionamento é um dos pontos importantes na modelagem de dados, pois representa
a arte de fazer uma engenharia de dados com
perfeição.
-RELACIONAMENTOS COM ENTIDADES:

Na modelagem de dados, há um item que exige um estudo minucioso para relacionar
todas as entidades envolvidas num modelo de dados.
A solução disso é analisar todas as dependências possíveis entre as entidades; para
isso, utiliza-se o atributo para verificar a dependência.
Em um DER, um relacionamento é representado por meio de um losango, que liga por
traços as entidades. No lugar das linhas também são
colocados informações de cardinalidades – o que será detalhado oportunamente.
Quando se analisa o relacionamento entre as entidades, levando em conta os
conteúdos das entidades, utiliza-se o conteúdo dos atributos para
verificar a dependência. Temos duas entidades: na entidade Empregado, temos um
atributo chamado nome; na entidade Departamento, temos
o atributo Setor. Analisando a figura, observamos que João trabalha no setor de
Contabilidade, e que o setor de Contabilidade tem um empregado
de nome João. Note que perguntamos da entidade Empregado na direção da entidade
Departamento, e também perguntamos do Departamento
na direção do Empregado. Há que se fazer a pergunta nas 2 direções, da esquerda
(Empregado) para direita (Departamento) e da direita
(Departamento) para a esquerda (Empregado).
-RELACIONAMENTOS COM ATRIBUTOS:

O atributo é o principal mecanismo para analisar os relacionamentos entre as
entidades, levando em conta os conteúdos dos atributos.
-CARDINALIDADES:
O modelo DER permite expressar cardinalidades mínimas e máximas em cada
relacionamento. A cardinalidade mínima 1 também recebe a
denominação de “associação obrigatória”, já que ela indica que o relacionamento
deve obrigatoriamente associar uma ocorrência de entidade
a cada ocorrência da entidade em questão.
Com base na mesma linha de raciocínio, a cardinalidade mínima 0 recebe a
denominação de “associação opcional”.
Representação: (cardinalidade mínima, cardinalidade máxima), Cardinalidades
Possíveis: (1,1); (1,N); (0,1); (0,N); (N,N).
CARDINALIDADES DE ATRIBUTOS:
Vamos analisar a cardinalidade do próprio atributo, o quanto cada informação pode
ter variação de conteúdo para cada atributo. Podemos
classificar em vários tipos de análises.
a) Monovalorado: possui um valor único para cada atributo mostrado na entidade. No
mundo real só existe um CPF por pessoa e só existe um
nome por pessoa para cada empregado. Quando há homônimos de nomes, o CPF torna
único o empregado, só existe um endereço para cada
empregado.
b) Multivalorado: dos atributos mencionados na figura 10, no caso o CPF, Nome e
Endereço, são monovalorados, por possuírem somente um
conteúdo, enquanto que o telefone é multivalorado, porque pode possuir vários
conteúdos: tem 2 números celulares, tem um número de telefone
residencial, tem um número de telefone comercial e tem um número de telefone de
contato. Juntando os telefones, temos cinco números de
telefones, por isso esse atributo é considerado multivalorado.
c) Autorrelacionamento (Relacionamento Unário): neste caso, na entidade Empregado,
o atributo Nome ora pode ser de um Supervisor, ora de
um subordinado; portanto, no relacionamento, podemos ter um atributo identificado
para todos os empregados, o qual é o tipo de empregado,
se é supervisor ou subordinado.
d) Relacionamento Binário: o relacionamento binário envolve a associação de duas
entidades. Podemos classificar os relacionamentos binários
de várias maneiras, em N:N (muitos-para-muitos), 1:N (um-para-muitos) e 1:1 (um-
para-um). O relacionamento entre as entidades Empregado e
Departamento, tem uma associação de relacionamento perguntando do empregado na
direção do departamento, na ordem 1 para N
(um-para-muitos), e perguntando do departamento na direção do empregado, deduzimos
que um departamento qualquer só tem um empregado,
na ordem de 1 para 1 (um-para-um).
e) Relacionamento Entidade Associativa: Toda vez que temos um relacionamento de N
para N (muitos-para-muitos), o conteúdo de um CPF
pode ter vários números de contas da entidade Conta Corrente, de um para muitos
(1:N), perguntado da entidade conta corrente na direção da
entidade cliente; se perguntarmos que o conteúdo de número de conta pode ter vários
CPFs (casos de conta conjunta), portanto, conclui-se que
o relacionamento é N para N (muitos-para-muitos). Nesse caso, criamos uma entidade
nova chamada Cliente x Conta Corrente, juntando os
atributos-chave CPF da entidade Cliente com o atributo Número Conta da entidade
Conta Corrente. Essa junção deverá fazer parte da nova
entidade Cliente x Conta Corrente; pelo fato desta junção ser chave em outras
entidades, chamamos esses atributos de chave estrangeira, e
ainda juntamos com a chave estrangeira mais um atributo: Data de Lançamento,
próprio da tabela Cliente x Conta. A entidade Cliente x Conta
Corrente terá as chaves compostas dos atributos CPF do Cliente + Número da Conta +
Data Lançamento.
-IDENTIFICADOR ATRIBUTO CHAVE ÚNICA:

Cada entidade deve ter um identificador, ou seja, um atributo-chave: é o conjunto
de um ou mais atributos cujos valores servem para distinguir
uma ocorrência única em toda entidade. Exemplo: o atributo CPF está com o círculo
do Cliente preenchido de vermelho e também os atributos
Número Corredor + Número Prateleira, formando uma chave composta. Essa chave
composta garante uma chave como único conteúdo dentro
da entidade Prateleira.
Os conceitos entre Entidade Forte e Entidade Fraca: na Entidade Forte há um
atributo que pode ser chave única para toda a entidade.
A figura 15 mostra que o CPF é um atributo que garante ser chave única na entidade
EMPREGADO. Nessa situação, podemos considerar a
entidade DEPENDENTE como entidade forte, enquanto que na entidade DEPENDENTE, o
atributo CPF Empregado não é suficiente para
garantir como chave única; nesse caso, precisamos criar um atributo artificial –
que é chamado de artificial porque não veio da regra de negócio,
é idealizado pelo técnico que cria o modelo de dados. Esse atributo chama-se número
do dependente. Com os atributos, podemos agora ter
uma chave única para a entidade DEPENDENTE, constituído por chave composta.
Exemplo: CPF 1 – Esposa (Número de Dependente 1),
CPF 1 – Filho 1 (Número de Dependente 2), CPF 1 – filho 2 (Número de Dependente 3),
com isso, termos as chaves: 11, 12, 13, o que garante a
unicidade de chave na entidade.
-EXEMPLO DE UM PROJETO LÓGICO NA TERCEIRA FORMA NORMAL:

A modelagem está na terceira forma normal, conforme conceitos apresentados no
módulo. Antes, é necessário esclarecer sobre a utilização
das figuras: todas as figuras em cor verde referem-se a entidades que são obtidas
das regras de negócios relatadas pelo usuário; todas as figuras
em cor laranja são criação do técnico que elabora o modelo de dados, para
possibilitar a eliminação de dados redundantes (duplicidades),
e também para conceber uma construção de atributos-chave que permitam um acesso ou
atualização dos dados com níveis de desempenho
que venha a garantir um tempo de resposta com excelência. As figuras em cor azul
são os meios de relacionamentos entre as entidades.
Em toda a entidade em cor laranja temos uma relação de N:N (muitos-para-muitos),
por isso, o técnico na modelagem de dados cria uma
entidade chamada de associativa, trazendo os atributos de chave estrangeira das
entidades envolvidas no relacionamento.
É muito interessante observar que, toda vez que criamos uma entidade associativa,
colocamos os nomes das duas entidades associadas.
Por exemplo: Professor x Curso, e isso vale para as demais entidades associativas.
O modelo está pronto para uma ferramenta Case – própria para modelagem de dados –,
por exemplo, a que foi estudada anteriormente
(DBDesignerfork), e então construirmos o Diagrama de Entidade e Relacionamento
(DER).
-CONCEITOS DO PROJETO FÍSICO:

O projeto físico tem como origem o projeto lógico, que é a modelagem de dados, o
chamado Diagrama de Entidade e Relacionamento (DER),
que pode ser construído com a ferramenta Case DBDesignerfork. Podemos observar que
todo atributo-chave tem, antes do atributo, um desenho
de chave e que, quando temos chaves compostas, há uma divisão em que acima ficam os
atributos-chave e abaixo ficam os atributos não
chave – com um desenho de um losango antes do atributo.
UTILIZAÇÃO DE COMANDOS SQL PARA CRIAÇÃO E MANUTENÇÃO DE DADOS:

Todo o processo de aprendizado é realizado numa ferramenta IDE Workbench MySQL para
fixar os conhecimentos explicados de forma prática.
Há uma preocupação em esclarecer de forma ilustrada e prática cada passo, desde a
criação de Bancos de Dados e “Schema”, a conversão
de modelo lógico em linguagem DML (linguagem de manipulação de dados) para criação
de tabelas, que mostra os resultados após a
execução dos scripts.
O aprendizado de bancos se apoia na prática da manutenção de “Schema”, tabelas,
linhas e colunas, construção de índices. Também são
demonstrados: a execução de comandos DDL (Data Definition Language) de forma
prática, a manipulação de dados com comandos do SQL,
por exemplo, a Inclusão de dados (Insert), alteração de dados (Update), exclusão de
dados (Delete) e consulta de Dados (Select).
Vamos demonstrar a criação de um banco de dados tomando como exemplo um modelo
completo de dados que contempla todas as situações
que compõem o entendimento de conhecimento da engenharia de bancos de dados,
possibilitando ao leitor uma capacitação para
desempenhar com facilidade as atividades pertinentes a banco de dados.
CRIAÇÃO DE BANCOS DE DADOS:

A criação de tabela tem o objetivo de reunir um conjunto de tabelas, o qual podemos
referenciar para o acesso às tabelas e para realizar as
conexões com aplicativos ou servidor de banco de dados.
Um exemplo para criarmos um banco de dados, de nome “test”, é o seguinte:
CREATE DATABASE test;
CREATE USER ‘test’ IDENTIFIED BY;
Quando criamos um banco dados, torna-se necessário conceder um acesso, que pode ser
implementado com a execução da instrução
“CREATE USER ‘test’ IDENTIFIED BY”, sendo que o que vem após o BY é a informação de
uma senha, por exemplo, “1234”, que deverá ser
informada toda vez que se fizer uma conexão com o banco de dados.
CRIAÇÃO DE SCHEMA:
A permissão de um “Schema” pode ser concedida para usuários e grupos de usuários.
Quando o usuário tem acesso a um “Schema”, ele tem
autorização para acessar todas às tabelas que compõem o “Schema”.
Em segmentação de dados por grupo de usuários, você pode ter na mesma database duas
tabelas com o mesmo nome, estando cada uma em
um “Schema” diferente.
Conceitualmente, um “Schema” é um conjunto de objetos de banco de dados inter-
relacionados, como tabelas, colunas, tipos de dados, índices,
chaves estrangeiras, e assim por diante. Esses objetos estão conectados por meio da
sintaxe SQL porque as colunas compõem as tabelas,
chaves estrangeiras e referenciam essas colunas.
No MySQL, fisicamente, um “Schema” é sinônimo de um banco de dados. É possível
substituir a palavra-chave SCHEMA por DATABASE na
sintaxe SQL do MySQL, por exemplo, utilizando CREATE SCHEMA em vez de CREATE
DATABASE. O comando para criar um “Schema” tem a
seguinte sintaxe: CREATE SCHEMA ‘teste1’.
Quando criamos o “Schema” tem-se o mesmo efeito de criar o Banco de Dados. Por
exemplo, conforme demonstrado na figura 1, podemos
notar que o “test” que foi criado com a sintaxe 2 CREATE DATABASE test gerou um
“Schema” chamado “test” e utilizando CREATE SCHEMA
‘teste1’ também gerou um “Schema” chamado “teste2”.
EXCLUSÃO DE BANCO DE DADOS OU SCHEMA:
Para excluir um “Schema”, utilizamos a seguinte sintaxe de comandos:
DROP SCHEMA ‘teste2’
CRIAÇÃO DE COLUNAS:
Há configurações que precisamos entender quando da criação das colunas (campos)
dentro de uma tabela. Temos que estabelecer um
tamanho de coluna que seja suficiente para comportar o conteúdo da informação, de
acordo com a regra de negócio; e que o dimensionamento
do tamanho da coluna possa suportar, por um bom tempo, frente ao aumento das
informações por parte do usuário.
Também deve ser definido qual o tipo da informação ideal – que deve ser compatível
com a regra de negócio do usuário.
Tipos de Dados:
TINYINT = Número inteiro muito pequeno (tiny).
SMALLINT = Número inteiro pequeno.
MEDIUMINT = Número inteiro de tamanho médio.
INT = Número inteiro de tamanho comum.
BIGINT = Número inteiro de tamanho grande.
FLOAT = Número de ponto flutuante de precisão simples (32 bits).
DOUBLE = Número de ponto flutuante de precisão dupla (64 bits).
DECIMAL (N,D) = Número decimal, com N = inteiro e D = Decimal.
Tipos de Alfanuméricos – Strings:

CHAR() = Cadeia de caracteres (string), de tamanho fixo de acordo com N.
VARCHAR() = String de tamanho variável de acordo com N.
BINARY = Número inteiro de tamanho médio.
VARBINARY = String binária de tamanho fixo.
BLOB = Binary Large OBject – Objeto Grande Binário
TINYBLOB = Um BLOB muito pequeno.
MEDIUMBLOB = Um BLOB de tamanho médio.
LONGBLOB = Um BLOB grande.
TINYTEXT = String não binária e de tamanho bem reduzido.
TEXT = String não binária e pequena.
MEDIUMTEXT = String de tamanho comum e não binária.
LONGTEXT = String não binária de tamanho grande.
Tipos de Tempo:
DATE = valor referente a uma data no formato ‘AAAA-MM-DD’.
TIME = Valor horário no formato ‘hh:mm:ss’ (hora:minutos:segundos).
TIMESTAMP = “Timestamp” é uma sequência de caracteres ou informação codificada que
identifica uma marca temporal ou um dado
momento em que um evento ocorreu. Tem o formato ‘AAAA-MM-DD hh:mm:ss’.
YEAR = Armazena um ano no formato ‘CCYY’ ou ‘YY’
ALTERAÇÃO DE COLUNAS:
Às vezes, surge a necessidade de aumentar o tamanho ou o tipo de dados de uma
coluna. Quando isso acontece, podemos fazer com o
comando ALTER.
1. Criação de Tabelas
CREATE TABLE ‘teste2’.‘produto’ (
‘PRODUTOCODIGO’ INT NOT NULL,
‘PRODUTODESCRICAO’ VARCHAR(45) NULL);
a) Alteração da coluna de Tabelas
Na alteração vamos mudar o tamanho da coluna ‘PRODUTODESCRICAO’ VARCHAR(45) NULL)
para ‘PRODUTODESCRICAO’ VARCHAR(50)
NULL); para isso, vamos executar a seguinte sintaxe:
ALTER TABLE ‘teste2’.‘produto’
CHANGE COLUMN ‘PRODUTODESCRICAO’ ‘PRODUTODESCRICAO’ VARCHAR(50) NULL DEFAULT NULL.
EXCLUSÃO DE COLUNAS:
Às vezes, surge a necessidade de excluir uma coluna. Podemos fazer com o comando
DROP.
ALTER TABLE ‘teste2’. ‘produto’
DROP COLUMN ‘PRODUTODESCRICAO’.
INCLUIR UMA COLUNA:
Para incluir uma coluna ou mais numa tabela já existente, podemos fazer com o
comando CHANGE.
ALTER TABLE ‘teste2’.‘produto’
CHANGE COLUMN ‘PRODUTODESCRICAO’ VARCHAR(60) NULL.
CRIAÇÃO DE TABELAS:
A tabela nasce com um nome e se compõe de linhas (Registro) e colunas (Campos);
contém definições de tamanho e tipo de cada coluna.
Contém nomes de colunas, definição de coluna chave, e definição de chaves
estrangeiras. As linhas e as colunas servem de referência para
armazenar os conteúdos dos dados.
Chave Primária (Primary Key) é uma ou mais colunas com valores que são únicos
dentro da tabela e, por isso, podem ser usados para
identificar as linhas dessa tabela.
Há uma série de parâmetros que são considerados, no momento de criação de uma
tabela:
1. UNSIGNED – Modificador que faz com que uma coluna aceite apenas números
positivos (sem sinal). Somente para tipo “integer”.
2. ZEROFILL – Adiciona zeros de preenchimento à esquerda para completar um número;
por exemplo, se o campo tem 5 posições e temos o
conteúdo de 235, o resultado fica 00235.
3. AUTO_INCREMENT – Campo que soma automática e sequencialmente mais 1 ao conteúdo
anterior.
4. ON DELETE NO ACTION - Exclui somente o pai sem afetar o(s) registro(s) filhos ou
relacionados em outras entidades.
5. ON DELETE CASCADE – É a exclusão com efeito realizado em cascata, quando se
exclui o registro de uma tabela principal, também exclui
todos os registros de outras tabelas com conteúdo associado por chaves estrangeiras
à tabela principal.
6. CASCADE: A opção CASCADE permite excluir ou atualizar os registros relacionados
presentes na tabela filha automaticamente, quando um
registro da tabela pai for atualizado (ON UPDATE) ou excluído (ON DELETE). É a
opção mais comumente aplicada.
7. RESTRICT: Impede que ocorra a exclusão ou a atualização de um registro da tabela
principal, caso haja alguma tabela com conteúdo
associado à tabela principal com chave estrangeira. A verificação de integridade
referencial é realizada antes de tentar executar a instrução
UPDATE ou DELETE.
8. SET NULL: Esta opção é usada para definir com o valor NULL o campo na tabela
filha, quando um registro da tabela pai for atualizado ou
excluído.
9. NO ACTION: Essa opção equivale à opção RESTRICT, porém a verificação de
integridade referencial é executada após a tentativa de alterar
a tabela. É a opção padrão, aplicada caso nenhuma das opções seja definida na
criação da chave estrangeira.
10. SET DEFAULT: “Configura Padrão” – Define um valor padrão na coluna na tabela
filha, aplicado quando um registro da tabela pai for
atualizado ou excluído.
11. PRIMARY KEY (PK): Esta restrição cria um índice único para um conjunto de
colunas ou uma coluna para Chave Primária.
12. UNIQUE: Esta Contraint determina que uma coluna não poderá ter duas linhas com
o mesmo valor.
13. FOREIGN KEY (FK ou Chave Estrangeira): Determina uma ou mais colunas, a qual se
considera o seu conteúdo como único dentro da
tabela.
14. CHECK: Especifica uma condição lógica que condiciona para efetivar o salvamento
da tabela.
15. NOT NULL: Determina que a coluna tem preenchimento obrigatório.
Um exemplo para criação de tabela (abaixo) explicado:
CREATE TABLE ‘test’.‘alunoxdisciplina’ (
‘test’ class="">‘test’ - corresponde ao nome do banco de dados ou “schema”
‘alunoxdisciplina’ - Corresponde o nome da tabela
‘Aluno_CPF’ INT(10) UNSIGNED NOT NULL,
‘Aluno_CPF’ – Nome da Coluna ou Campo.
INT –Tipo da coluna (campo).
UNSIGNED - Aceite apenas números positivos.
NOT NULL – Coluna com conteúdo obrigatório.
‘Disciplina_Codigo’ INT(10) UNSIGNED NOT NULL,
‘Disciplina_Codigo’ – Nome da Coluna ou Campo.
INT –Tipo da coluna (campo).
UNSIGNED - Aceite apenas números positivos.
NOT NULL – Coluna com conteúdo obrigatório.
‘Alunoxdisciplina_DataValidade’ DATE NULL DEFAULT NULL,
‘Alunoxdisciplina_DataValidade’ – Nome da Coluna ou Campo.
DATE – Tipo da coluna que aceita somente conteúdo no formato data (DD/MM/AAA).
NULL – Coluna com conteúdo opcional.
DEFAULT NULL – Quando o campo não for informado, assume o NULL, sem ser necessário
ter um conteúdo obrigatório.
PRIMARY KEY (‘Aluno_CPF’, ‘Disciplina_Codigo’),
PRIMARY KEY – Chave primária com único conteúdo em toda tabela.
‘Aluno_CPF’ – Nome da primeira coluna da chave primária.
‘Disciplina_Codigo’ – Nome da segunda coluna da chave primária.
INDEX ‘AlunoXDisciplina_FKIndex1’ (‘Disciplina_Codigo’ ASC) VISIBLE,
INDEX – Primeiro índice da chave estrangeira (Foreign Key).
‘AlunoXDisciplina_FKIndex1’ – Nome do primeiro índice da chave estrangeira (Foreign
Key).
ASC – Classificação do índice de forma crescente do menor para o maior.
VISIBLE – Significa que índice está sempre disponível para usá-lo.
INDEX ‘AlunoXDisciplina_FKIndex2’ (‘Aluno_CPF’ ASC) VISIBLE,
Idem as mesmas configurações da primeira chave estrangeira.
CONSTRAINT ‘alunoxdisciplina_ibfk_1’
CONSTRAINT – Coluna com restrição que só permite a criação da tabela desde que
conteúdo esteja presente na tabela pai (principal).
‘alunoxdisciplina_ibfk_1’ – Nome de referência da primeira chave estrangeira.
FOREIGN KEY (‘Disciplina_Codigo’)
FOREIGN KEY – Comando de indicação de chave estrangeira.
‘Disciplina_Codigo’ – Nome da coluna da chave estrangeira referente a nome em outra
tabela pai (Principal).
REFERENCES ‘test’.‘disciplina’ (‘Disciplina_Codigo’)
REFERENCES – Comando para referenciar a outra tabela pai (principal) onde tem a
chave de origem.
‘test’ – Nome do Banco ou esquema onde existe a tabela com chave de origem para ser
chave estrangeira.
‘disciplina’ – Nome tabela onde com chave de origem para ser a chave estrangeira.
‘Disciplina_Codigo’ – Nome da coluna (campo) de origem da chave estrangeira.
ON DELETE NO ACTION
ON DELETE – Quando houver exclusão de linha (registro).
Exclui somente o pai sem afetar o(s) registro(s) filhos ou relacionados em outras
entidades.
ON UPDATE NO ACTION,
ON UPDATE – Quando houver alteração de coluna (campo) na linha (registro).
Altera somente o pai sem afetar o(s) registro(s) filhos ou relacionados em outras
entidades.
FOREIGN KEY (‘Aluno_CPF’)
REFERENCES ‘test’.‘aluno’ (‘Aluno_CPF’)
ON DELETE NO ACTION
ON UPDATE NO ACTION);
CONCESSÃO DE ACESSO A TABELAS – PRIVILÉGIOS:
Quando se cria um “Schema”, é possível conceder acesso e privilégios por meio do
seguinte comando:
GRANT ALL PRIVILEGES ON test.* TO testecursoxdisciplina
CRIAÇÃO DE CHAVE ESTRANGEIRA:
Toda que vez que temos uma relação terceira forma normal entre tabelas, temos de
juntar as chaves de duas tabelas numa terceira tabela,
chamada de entidade associativa.
EXECUÇÃO DE SCRIPTS DE UM MODELO DE DADOS PARA CRIAÇÃO DE TABELAS:
A partir de um modelo de dados criado na ferramenta DBDesignerfork, foi gerado um
script completo em linguagem DML. Esse script foi
executado na ferramenta IDE Workbench do MySQL, o resultado foi a criação de todas
as tabelas. A partir das tabelas criadas, foi gerado um
modelo lógico dentro da ferramenta Workbench, o que resultou numa figura gráfica do
DER, conforme apresentado no item anterior, semelhante
ao modelo lógico da fermenta DBDesignerfork.
CREATE TABLE ‘test’.‘aluno’ (
‘Aluno_CPF’ INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
‘Aluno_Nome’ VARCHAR(40) NULL DEFAULT NULL,
PRIMARY KEY (‘Aluno_CPF’));
-- -----------------------------------------------------
CREATE TABLE ‘test’.‘disciplina’ (
‘Disciplina_Codigo’ INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
‘Disciplina_Nome’ VARCHAR(40) NULL DEFAULT NULL,
‘Disciplina_Creditos’ INT(10) UNSIGNED NULL DEFAULT NULL,
PRIMARY KEY (‘Disciplina_Codigo’));
-- -----------------------------------------------------
CREATE TABLE ‘test’.‘alunoxdisciplina’ (
‘Alunoxdisciplina_DataValidade’ DATE NULL DEFAULT NULL,
PRIMARY KEY (‘Aluno_CPF’, ‘Disciplina_Codigo’),
INDEX ‘AlunoXDisciplina_FKIndex1’ (‘Disciplina_Codigo’ ASC) VISIBLE,
INDEX ‘AlunoXDisciplina_FKIndex2’ (‘Aluno_CPF’ ASC) VISIBLE,
ON DELETE NO ACTION
REFERENCES ‘test’.’aluno’ (‘Aluno_CPF’)
ON DELETE NO ACTION
-- -----------------------------------------------------
CREATE TABLE ‘test’.‘turma’ (
‘Turma_Numero’ INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
‘Turma_Sala’ INT(10) UNSIGNED NULL DEFAULT NULL,
‘Turma_Horario’ DATETIME NULL DEFAULT NULL,
PRIMARY KEY (‘Turma_Numero’));
-- -----------------------------------------------------
CREATE TABLE ‘test’.‘alunoxturma’ (
‘Turma_Numero’ INT(10) UNSIGNED NOT NULL,
‘Alunoxturma_DataValidade’ DATE NULL DEFAULT NULL,
PRIMARY KEY (‘Turma_Numero’, ‘Aluno_CPF’),
INDEX ‘AlunoXTurma_FKIndex1’ (‘Turma_Numero’ ASC) VISIBLE,
INDEX ‘AlunoXTurma_FKIndex2’ (‘Aluno_CPF’ ASC) VISIBLE,
CONSTRAINT ‘alunoxturma_ibfk_1’
FOREIGN KEY (‘Turma_Numero’)
REFERENCES ‘test’.‘turma’ (‘Turma_Numero’)
ON DELETE NO ACTION
CONSTRAINT ‘alunoxturma_ibfk_2’
ON DELETE NO ACTION
-------------------------------------------------------
CREATE TABLE ‘test’.‘curso’ (
‘Curso_Codigo’ INT(10) UNSIGNED NOT NULL,
‘Curso_Descricao’ VARCHAR(40) NOT NULL,
PRIMARY KEY (‘Curso_Codigo’));
-------------------------------------------------------
CREATE TABLE ‘test’.‘cursoxdisciplina’ (
‘Cursoxdisciplina_DataValidade’ DATE NULL DEFAULT NULL,
PRIMARY KEY (‘Curso_Codigo’, ‘Disciplina_Codigo’),
INDEX ‘CursoxDisciplina_FKIndex1’ (‘Disciplina_Codigo’ ASC) VISIBLE,
INDEX ‘CursoxDisciplina_FKIndex2’ (‘Curso_Codigo’ ASC) VISIBLE,
CONSTRAINT ‘cursoxdisciplina_ibfk_1’
ON DELETE NO ACTION
CONSTRAINT ‘cursoxdisciplina_ibfk_2’
FOREIGN KEY (‘Curso_Codigo’)
REFERENCES ‘test’.‘curso’ (‘Curso_Codigo’)
ON DELETE NO ACTION
-------------------------------------------------------
-- Table ‘test’.‘professor’
-------------------------------------------------------
CREATE TABLE ‘test’.‘professor’ (
‘Professor_CPF’ INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
‘Professor_Nome’ VARCHAR(40) NULL DEFAULT NULL,
‘Professor_Endereco’ VARCHAR(40) NULL DEFAULT NULL,
PRIMARY KEY (‘Professor_CPF’));
-------------------------------------------------------
CREATE TABLE ‘test’.‘professorxaluno’ (
‘Professor_CPF’ INT(10) UNSIGNED NOT NULL,
‘Professorxaluno_DataValidade’ DATE NULL DEFAULT NULL,
PRIMARY KEY (‘Professor_CPF’, ‘Aluno_CPF’),
INDEX ‘ProfessorXAluno_FKIndex1’ (‘Aluno_CPF’ ASC) VISIBLE,
INDEX ‘ProfessorXAluno_FKIndex2’ (‘Professor_CPF’ ASC) VISIBLE,
CONSTRAINT ‘professorxaluno_ibfk_1’
ON DELETE NO ACTION
CONSTRAINT ‘professorxaluno_ibfk_2’
FOREIGN KEY (‘Professor_CPF’)
REFERENCES ‘test’.‘professor’ (‘Professor_CPF’)
ON DELETE NO ACTION
-------------------------------------------------------
CREATE TABLE ‘test’.‘professorxcurso’ (
‘Professorxcurso_DataValidade’ DATE NULL DEFAULT NULL,
PRIMARY KEY (‘Professor_CPF’, ‘Curso_Codigo’),
INDEX ‘ProfessorXCurso_FKIndex1’ (‘Professor_CPF’ ASC) VISIBLE,
INDEX ‘ProfessorXCurso_FKIndex2’ (‘Curso_Codigo’ ASC) VISIBLE,
CONSTRAINT ‘professorxcurso_ibfk_1’
ON DELETE NO ACTION
CONSTRAINT ‘professorxcurso_ibfk_2’
FOREIGN KEY (‘Curso_Codigo’)
REFERENCES ‘test’.‘curso’ (‘Curso_Codigo’)
ON DELETE NO ACTION
-------------------------------------------------------
CREATE TABLE ‘test’.‘professorxturma’ (
‘Professorxturma_DataValidade’ DATE NULL DEFAULT NULL,
PRIMARY KEY (‘Professor_CPF’, ‘Turma_Numero’),
INDEX ‘ProfessorXTurma_FKIndex1’ (‘Professor_CPF’ ASC) VISIBLE,
INDEX ‘ProfessorXTurma_FKIndex2’ (‘Turma_Numero’ ASC) VISIBLE,
CONSTRAINT ‘professorxturma_ibfk_1’
ON DELETE NO ACTION
CONSTRAINT ‘professorxturma_ibfk_2’
ON DELETE NO ACTION
-------------------------------------------------------
CREATE TABLE ‘test’.‘turmaxdisciplina’ (
‘Turmaxdisciplina_DataValidade’ DATE NULL DEFAULT NULL,
PRIMARY KEY (‘Turma_Numero’, ‘Disciplina_Codigo’),
INDEX ‘TurmaXDisciplina_FKIndex1’ (‘Disciplina_Codigo’ ASC) VISIBLE,
INDEX ‘TurmaXDisciplina_FKIndex2’ (‘Turma_Numero’ ASC) VISIBLE,
CONSTRAINT ‘turmaxdisciplina_ibfk_1’
ON DELETE NO ACTION
CONSTRAINT ‘turmaxdisciplina_ibfk_2’
ON DELETE NO ACTION
ON UPDATE NO ACTION)
MODELO DE DADOS APÓS CRIAÇÃO DE TABELAS NO IDE WORKBENCH MYSQL:
Para converter as tabelas criadas em um modelo lógico, por meio de uma opção do
Workbench, clicar no seguinte caminho:
Database/Reverse Engineer/Connect to DBMS/Select Schemas. Após isso, será gerado o
modelo lógico.
MANIPULAÇÃO DE DADOS:
Para manipulação de dados é utilizada a linguagem DML (Data Manipulation Language),
que é aplicada universalmente dentro de linguagens
de aplicativos com compatibilidade de 100%.
Os comandos DML estão dentro da linguagem SQL (Structured Query Language), servem
para realizar a manipulação de dados, Consulta de
dados (Select), Inclusão de dados (Insert), Exclusão de dados (Delete) e Alteração
de dados (Update).
A linguagem SQL é basicamente dividida em três tipos de comandos: SQL = DDL + DML +
DCL:
1. DDL (definição de dados): Comandos: CREATE, DROP, ALTER
2. DML (manipulação de dados): Comandos: SELECT, INSERT, UPDATE e DELETE
3. DCL (controle de dados): Comandos: GRANT e REVOKE
4. Os comandos de manipulação de dados (DML) em SQL são representados por:
● INSERT: permite a inclusão de novas linhas nas tabelas.
● UPDATE: altera os valores de dados já cadastrados.
● DELETE: remove dados já cadastrados.
● SELECT: usado para consultar o BD e retornar dados que satisfazem a determinada
expressão em um comando.
INCLUSÃO DE DADOS:
Nos comandos DML da linguagem SQL (Structured Query Language) são executadas as
inclusões (Insert) nas tabelas: Aluno, Disciplina e
Alunoxdisciplina, conforme descrito anteriormente.
INCLUSÃO DE DADOS DA TABELA ALUNO:
INSERT INTO ‘test’.‘aluno’ (‘Aluno_CPF’,‘Aluno_Nome’) VALUES (1,“João”);
INSERT INTO ‘test’.‘aluno’ (‘Aluno_CPF’,‘Aluno_Nome’) VALUES (2,“Antonio”);
INSERT INTO ‘test’.‘aluno’ (‘Aluno_CPF’,‘Aluno_Nome’) VALUES (3,“José”);
INCLUSÃO DE DADOS DA TABELA DISCIPLINA:
INSERT INTO ‘test’.‘disciplina’ (‘Disciplina_Codigo’, ‘Disciplina_Nome’,
‘Disciplina_Creditos’) VALUES (1, “Engenharia”,10);
‘Disciplina_Creditos’) VALUES (2, “Direito”,30);
‘Disciplina_Creditos’) VALUES (3, “Matemática”,50);
INCLUSÃO DE DADOS DA TABELA ALUNOXDISCIPLINA:
INSERT INTO ‘test’.‘alunoxdisciplina’ (‘Aluno_CPF’, ‘Disciplina_Codigo’,
‘Alunoxdisciplina_DataValidade’) VALUES (1, 1, “2019/09/23”);
Devemos observar que, antes de fazer os “Inserts” dos dados chave da tabela
Alunoxdisciplina, deve-se providenciar os “Inserts” dos conteúdos
dos dados Aluno_CPF na tabela Aluno e Disciplina_Codigo na tabela Disciplina. Se
isso não for feito, inviabiliza o insert da tabela
Alunoxdisciplina.
Abaixo vamos reexecutar um insert de conteúdo de dados na tabela Alunoxdisciplina.
Quando tentamos reinserir os mesmos dados já antes cadastrados na tabela
Alunoxdisciplina, ocorre um erro “Duplicate entry for key
PRIMARY”, por tratar-se de dados da chave estrangeira (ocorrência de somente uma
vez em toda tabela), sendo recusada a inclusão dos dados.
EXCLUSÃO DE DADOS:
Quando precisamos excluir uma linha (registro) da tabela, é necessário que os dados
já existam na tabela.
Vamos executar a instrução de exclusão de dados abaixo. Observamos que temos a
cláusula Where para selecionar em qual linha devemos
excluir. No Caso do Where comparamos os campos de chave primária, Aluno_CPF = 1 and
Disciplina_Codigo = 3.
DELETE FROM ‘test’.‘alunoxdisciplina’ WHERE Aluno_CPF = 1 and Disciplina_Codigo =
3;
Quando tentamos fazer a mesma exclusão pela segunda vez, executamos a instrução
abaixo.
DELETE FROM ‘test’.‘alunoxdisciplina’ WHERE Aluno_CPF = 1 and Disciplina_Codigo =
3;
Quando tentamos fazer a mesma exclusão pela segunda vez, ocorre de não concluir a
exclusão, porque os dados não existem mais.
ALTERAÇÃO DE DADOS:
Quando precisamos alterar dados na tabela, é necessário que os dados já existam
nela.
Vamos executar a instrução de alteração de dados conforme abaixo. Observamos que
temos a cláusula Where para selecionar em qual linha
devemos alterar. No Caso do Where comparamos os campos de chave primária,
‘Aluno_CPF’ = 3 AND ‘Disciplina_Codigo’ = 2. Ainda, a
cláusula SET define qual a coluna deve ser alterada, e após o sinal de igual,
coloca-se o conteúdo novo que deve ser alterado.
UPDATE ‘test’.‘alunoxdisciplina’ SET ‘Alunoxdisciplina_DataValidade’ = “2019/09/24”
WHERE ‘Aluno_CPF’ = 3 AND ‘Disciplina_Codigo’ = 2;
Quando tentamos fazer a mesma alteração pela segunda vez, executamos a instrução
abaixo.
UPDATE ‘test’.‘alunoxdisciplina’ SET ‘Alunoxdisciplina_DataValidade’ = “2019/09/24”
WHERE ‘Aluno_CPF’ = 3 AND ‘Disciplina_Codigo’ = 4;
Quando tentamos fazer a alteração de dados inexistente, ocorre de não concluir a
alteração, porque os dados não existem, apresenta uma
mensagem de “0 rows affected”.
CONSULTA DE DADOS:
Um dos comandos mais utilizados é á consulta de dados, em que podemos ter inúmeras
variações na forma de consulta; a mais simples é o
que consta abaixo, pois o “*” é mostrado em todas as colunas da tabela que se
deseja consultar.
SELECT * FROM ‘test’.‘alunoxdisciplina’;
Podemos selecionar a consulta conforme um critério; basta mencionarmos uma coluna
com o conteúdo que desejamos. A coluna pode ser
qualquer uma da tabela; se forem colunas da chave primária, o processo fica rápido,
se forem colunas que não sejam chave primária, o
processamento ficará demorado, principalmente se o volume de dados for além de
1.000 linhas, o que pode comprometer o tempo de resposta
do resultado. Para realizarmos uma experiência, executamos a instrução abaixo, na
qual selecionamos todas as linhas da coluna
Aluno_CPF = 1.
SELECT * FROM ‘test’.‘alunoxdisciplina’ where Aluno_CPF = 1;
Pode ocorrer quando executamos uma seleção de a comparação da coluna não encontrar
nenhuma linha que satisfaça a condição.
Para essa situação, executamos a instrução a seguir.
SELECT * FROM ‘test’.‘alunoxdisciplina’ where Aluno_CPF = 4;
Uma vez que não há nenhum registro que atenda a condição da seleção, o resultado
não mostra nenhum registro.
COMANDOS DE SQL PARA OPERAÇÕES AVANÇADAS DE BANCOS DE DADOS:

Conforme estudamos anteriormente, o aprendizado de bancos se apoia na prática na
manutenção de “Schema”, tabelas, linhas e colunas,
construção de índices. Bem como na execução de comandos DDL (Data Definition
Language) de modo prático, a manipulação de dados com
comandos do SQL, por exemplo, a Inclusão de dados (Insert), a alteração de dados
(Update), exclusão de dados (Delete) e consulta de Dados
(Select).
COMANDOS SQL GERAIS:

Alguns comandos de SQL ajudam e facilitam na operação da ferramenta IDE Workbench
MySQL. São instruções que geram consultas
interativas para saber sobre o sistema gerenciador de banco de dados (SGBD).
Essas instruções são executadas por meio de query (consultas), na ferramenta IDE.
Uma dessas instruções é verificar o diretório de tabelas.
Se quisermos saber informações sobre: quais são as colunas de uma tabela, qual é
chave primária, qual o tipo de dados de cada coluna,
tamanho de cada coluna, qual é a coluna tem geração automática de conteúdo
(auto_increment – que não aceita informações vinda do usuário)
Comando: show columns from {}
Se quisermos saber informações sobre a versão utilizada do IDE Workbench MySQL,
utilizamos o comando abaixo.
Comando: Select version()
Se quisermos saber informações sobre a data do sistema gerenciador de banco de
dados, utilizamos o comando abaixo
Select current_date
Se quisermos saber informações sobre o usuário do banco de dados, utilizamos o
comando abaixo
Comando: Select user()
OPERADORES RELACIONAIS:
Os operadores lógicos são aplicados para compor condições de decisões para realizar
uma consulta ou em situação de atualizações de
dados – são associados à cláusula “Where”.
Essas condições envolvem comparações entre o conteúdo de uma coluna com valor fixo
ou com uma variável do aplicativo, ou ainda com o
conteúdo de outra coluna.
> Maior que
< Menor que
= Igual a
<> Diferente de
>= Maior ou igual a
<= Menor ou igual a
TABELAS PARA USO DOS EXEMPLOS A SEGUIR:

Os “scripts” abaixo servem para criar tabelas na ferramenta IDE Workbench MySQL
para explicar os exemplos mostrados ao longo deste
documento. Servem para explicar o funcionamento e mostrar os resultados dos
comandos de SQL, citados em cada situação a seguir.
CREATE TABLE teste (
codigo int(11) NOT NULL AUTO_INCREMENT,
nome varchar(15) NOT NULL,
email varchar(30) DEFAULT NULL,
telefone varchar(8) DEFAULT NULL,
PRIMARY KEY (codigo));
CREATE TABLE funcionario (
Codigo Int (10) not null primary key,
Nome Char(40) not null,
Setor Char(2) not null,
Cargo Char(20) not null,
Salario Decimal(10,2) not null);
CREATE TABLE aluno (
ra INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
nome CHAR(30) NOT NULL)
nascimento DATE NOT NULL);
Create table clientes (
codigo int(10) primary key,
nome char(40) not null,
sobrenome char(40) not null,
idade int(10) not null,
endereco char(50) not null,
cidade char(20) not null,
estado char(2) not null,
cep int(9) not null);
Create table conta (
numero int(10) primary key,
valor decimal(10,2) not null,
vencimento date not null,
codcli int(3) not null);
Create table pedido (
nr int primary key,
cliente int,
valor decimal(15,2));
Create table funcionarios(
codigo_funcionario int,
nome varchar(50) );
Create table pagamentos(
codigo_pagto int,
valor decimal(10,2) );
Create table descontos(
codigo_desconto int,
valor decimal(10,2) );
Create table tbl_autores (
id_autor int,
codigo_Livro int,
descricao_Livro char (40),
autor_Livro char (40),
editora_livro char (40),
ano_livro int,
Preco_Livro decimal(10,2) );
CREATE TABLE contato (
codigo INT NOT NULL,
nome VARCHAR(45) NULL,
idade int null,
setor INT NULL,
cargo VARCHAR(45) NULL,
salario DECIMAL(15,2) NULL,
admissao DATE NULL,
PRIMARY KEY (codigo));
CLASSIFICAÇÃO DE DADOS:
É comum surgir a necessidade de fazermos uma consulta dos dados de uma tabela
ordenada por ordem crescente ou decrescente.
Para isso, utilizamos uma cláusula chamada de “ORDER BY”, que associamos com o
comando “Select”.
Incluir na tabela teste os seguintes dados:
INSERT INTO ‘teste2’.‘teste’ (‘codigo’, ‘nome’, ‘email’, ‘telefone’) VALUES (‘1’,
‘Elaine’, ‘a@a.com’, ‘33334444’);
‘Elaine’, ‘b@b.com’, ‘11112222’);
‘Elaine’, ‘b@b.com’, ‘22223333’);
Vamos classificar todas as linhas da tabela aluno, com duas colunas em diferentes
ordens: ordem de classificação, nascimento ordem
descendente (DESC), e nome em ordem ascendente (ASC).
Antes vamos executar uma inclusão de dados para podemos, em seguida, executar o
“select” com order by.
INSERT INTO aluno (ra, nome, nascimento) VALUES (1, “JOAO”, “2019/09/27”);
INSERT INTO aluno (ra, nome, nascimento) VALUES (2, “ANTONIO”, “2019/08/27”);
INSERT INTO aluno (ra, nome, nascimento) VALUES (3, “CARLOS”, “2019/08/26”);
INSERT INTO aluno (ra, nome, nascimento) VALUES (4, “ALVARO”, “2019/08/26”);
Select * from aluno order by nascimento desc, nome asc;
OPERADORES AUXILIARES:
Vamos trabalhar com a cláusula “Between” para fazer a seleção de linhas, obedecendo
a uma condição que atenda a um valor mínimo e valor
máximo. A condição está associada com a cláusula “Where”. A sintaxe tem a seguinte
estrutura: “<expressão> [Not] BETWEEN <mínimo> and
<máximo>”.
Antes, para podermos testar esta condição, faremos inclusão de dados na tabela
contatos:
INSERT INTO contato (codigo, nome, idade, setor, cargo, salario, admissao)
VALUES (20, ‘Aline Brito’, 20 , 2, ‘Supervisora’, 1700, ‘2019-09-05’);
VALUES (22, ‘Silvia Mendes’, 20, 2, ‘Gerente’, 2000, ‘2019-09-01’);
VALUES (24, ‘Moacir Campos’, 30, 2, ‘Programador’, 2000, ‘2019-09-10’);
VALUES (26, ‘Marcos Silva’, 30, 2, ‘Programador’, 2000, ‘2019-09-15’);
Após a execução do comando “Select * from contato where idade between 10 and 25;”,
foram selecionadas somente as linhas em que a
idade com conteúdo 20 que atende as condições do between.
Também temos outras formas de seleção por meio de condição com conteúdos
sequenciais. Para isso utilizamos a cláusula IN.
Vamos executar o comando “Select * from contato where idade in (20,25);”
Outra situação que podemos utilizar é a de verificar a existência de colunas que
tenham conteúdos de valores nulos ou não. Para testarmos
essa situação, vamos executar a instrução “Select * from contato where nome is NOT
null;” Se formos executar o comando “Select * from
contato where nome is null;”, não teremos nenhum resultado apresentado, pois a
coluna está definida como “NOT NULL”, ou seja, será exigido
um conteúdo quando da inclusão dos dados.
VERIFICAÇÃO DE CARACTERES:
Para verificar a sequência de caracteres dentro de uma coluna do tipo string (char
ou varchar), podemos utilizar a cláusula “where”, uma
condição baseada no uso do operador LIKE, e a sintaxe tem a seguinte configuração
de instrução: “<expressão> [NOT] LIKE <valor>”.
Primeiro exemplo, vamos verificar quando a coluna nome da tabela contato começa com
a letra “M”. Para isso, executamos o comando
“Select * From contato Where nome LIKE ‘M%’;”
Outro exemplo. Vamos verificar quando a coluna nome da tabela contato tenha a
segunda letra igual a “l”. Para isso, executamos o comando
“Select * From contato Where nome LIKE ‘_l%’;”
Elaboração própria.
Mais um exemplo. Vamos verificar quando a coluna nome da tabela contato tenha a
letra “o” em qualquer posição do nome. Para isso,
executamos o comando “Select * From contato Where nome LIKE ‘%o%’;”
FUNÇÕES AGREGADAS:
Existem funções no SQL que contribuem para realizar operações matemáticas e
estatísticas. uma relação de funções e o que cada função
pode resultar. Também para cada função é mostrado um exemplo de comando SQL.
Função Resultado Exemplo de comando SQL
AVG() Média aritmética SELECT AVG(Preco_Livro) FROM tbl_Livro;
MAX() Maior valor SELECT MAX(Preco_Livro) FROM tbl_Livro;
MIN() Menor valor SELECT MIN(Preco_Livro) FROM tbl_Livro;
SUM() Soma dos valores SELECT SUM(Preco_Livro) FROM tbl_Livro;
COUNT() Número de valores SELECT COUNT(*) FROM tbl_autores;
ALL Contagem dos valores não vazios SELECT COUNT(ALL id_autor) FROM
tbl_Livro;
Distinct Contagem dos valores não vazios e únicos SELECT COUNT(DISTINCT
id_autor) FROM tbl_Livro;
RELACIONAMENTO DE TABELAS:
Se houver necessidade de relacionar colunas entre duas ou mais tabelas, vamos
analisar que precisamos apresentar, ao mesmo tempo,
o número da conta da tabela conta e também nome do cliente da tabela cliente. Nesse
caso, podemos utilizar o comando SQL:
SELECT conta.numero, cliente.nome
FROM cliente, conta
WHERE cliente.codigo=conta.codcli;
Esse comando pode ser entendido como juntar as tabelas Cliente e Conta. O objetivo
é selecionar na comparação da cláusula “Where” através
do código do cliente ser igual ao codcli da tabela conta. Todas as linhas que
atenderem a essas condições do “Where” serão apresentadas às
colunas número da tabela conta e nome da tabela cliente.
INFORMAÇÕES AGRUPADAS:
Podem existir necessidades de agrupar as funções agregadas por alguma coluna para
obter uma somatória, média ou contagem, por uma
determinada coluna de uma tabela.
Para solucionar essa necessidade, devemos utilizar a cláusula WHERE com a cláusula
GROUP BY. Podemos resolver, tomando como
referência cinco exemplos de comando SQL.
1 SELECT codcli, COUNT(*) FROM conta GROUP BY codcli;
2 SELECT cliente.Nome, COUNT(*) FROM cliente, conta
WHERE cliente.codigo = cobranca.codcli
GROUP BY cliente.Nome;
3 SELECT codcli, avg(valor) FROM conta GROUP BY codcli having avg(valor)>2000;
4 Select codcli, sum (valor) From conta Group by codcli with ROLLUP;
O modificador ROLLUP faz com que o mysql retorne também as linhas totalizadas, ou
seja, o total por cliente e o total geral.
5 Select cliente.nome, conta.numero, sum (conta.valor)as total
From conta, cliente
where conta.codcli = cliente.codigo
Group by cliente.nome, conta.numero with ROLLUP;
QUALIFICADORES:
Quando utilizamos as funções matemáticas ou estatísticas para uma apresentação
fina, surge a necessidade de definirmos outro qualificador
para às funções. Quando utilizamos, podemos substituir por um nome que julgamos ser
o mais ideal. Para isso aplicamos uma cláusula “as”
para definir o novo nome.
Executar as seguintes inclusões de conta:
INSERT INTO ‘teste2’.‘conta’ (‘numero’, ‘valor’, ‘vencimento’, ‘codcli’) VALUES
(‘1’, ‘10’, ‘2019-08-29’, ‘1’);
(‘2’, ‘50’, ‘2019-08-29’, ‘1’);
(‘3’, ‘40’, ‘2019-08-28’, ‘1’);
(‘4’, ‘30’, ‘2019-08-28’, ‘2’);
(‘5’, ‘20’, ‘2019-08-28’, ‘2’);
(‘6’, ‘40’, ‘2019-08-28’, ‘3’);
(‘7’, ‘95’, ‘2019-08-29’, ‘4’);
Considerando os dados da tabela clientes, conforme ilustrado na figura 15, e mais
os dados da tabela conta, vamos executar o comando SQL a
seguir, a fim verificarmos como funciona a cláusula “AS”.
SELECT clientes.Nome, COUNT(*) AS contas, sum(conta.valor) as valor
FROM clientes, conta WHERE clientes.codigo = conta.codcli
GROUP BY clientes.Nome;
Após a execução do comando acima, verificamos, que o count(*) foi substituído pela
palavra “contas” e que sum (conta.valor) foi
substituído pela palavra “valor”.
SUBQUERY:
Uma subquery é um comando SELECT que faz uma seleção sobre outra seleção já feita
por outro SELECT.
A subquery deve ser colocada entre parênteses; deve ser colocada depois de um
operador de comparação, e a cláusula ORDER BY não deve
ser incluída em uma subquery.
Executar as seguintes inclusões:
INSERT INTO ‘teste2’.‘clientes’ (‘codigo’, ‘nome’, ‘sobrenome’, ‘idade’,
‘endereco’, ‘cidade’, ‘estado’, ‘cep’) VALUES (‘1’, ‘Jose’, ‘Lacerda’, ‘30’, ‘Rua
um numero 5’, ‘São Paulo’, ‘SP’, ‘00000100’);
‘endereco’, ‘cidade’, ‘estado’, ‘cep’) VALUES (‘2’, ‘Maria’, ‘Antonia’, ‘25’, ‘Rua
um numero 6’, ‘Araraquara’, ‘SP’, ‘00000200’);
‘endereco’, ‘cidade’, ‘estado’, ‘cep’) VALUES (‘3’, ‘Marco’, ‘Jose’, ‘25’, ‘Rua H
numero 30’, ‘Araraquara’, ‘SP’, ‘00000300’);
‘endereco’, ‘cidade’, ‘estado’, ‘cep’) VALUES (‘4’, ‘Aparicio’, ‘Alfredo’, ‘30’,
‘Rua X numero 15’, ‘Araraquara’, ‘SP’, ‘00000400’);
Vamos executar o seguinte Exemplo:
SELECT nome FROM clientes WHERE nome LIKE ‘M%’ AND cidade IN (SELECT cidade FROM
clientes where cidade LIKE ‘A%’);
O resultado do primeiro SELECT executado foram as linhas com códigos 2, 3 e 4, pois
existem 3 ocorrências que começam pela letra “A”, ou
seja, “Araraquara”. Dessas três linhas, o segundo SELECT executado seleciona os
nomes que começam por “M”. Temos a Maria e o Márcio,
que é o resultado final, pois o Aparício não é considerado.
JUNÇÃO DE TABELAS:
Utilizamos a cláusula WHERE para aplicar a junção de tabelas, conhecido termo em
inglês “JOINs” (relacionamentos).
A cláusula JOIN é usada para associar dados de duas ou mais tabelas do banco de
dados. Temos duas categorias de joins:
a) INNER JOIN: Retorna linhas (registros) quando houver pelo menos uma
correspondência em ambas as tabelas pela cláusula “where”.
b) OUTER JOIN: Retorna linhas (registros) mesmo quando não houver ao menos uma
correspondência em uma das tabelas (ou ambas).
No caso do OUTER JOINS. Há três tipos de aplicações:
a) LEFT JOIN: Retorna todas as linhas da tabela à esquerda, mesmo se não houver
nenhuma correspondência na tabela à direita.
b) RIGHT JOIN: Retorna todas as linhas da tabela à direita, mesmo se não houver
nenhuma correspondência na tabela à esquerda.
c) FULL JOIN: Retorna linhas quando houver uma correspondência em qualquer uma das
tabelas.
Para criar uma alias para uma tabela, basta acrescentar um identificador à frente
do nome da tabela. A partir de então, basta utilizar este alias
para se referenciar à tabela, por exemplo, “p” para pedido, “c” para clientes.
Select nome,nr,valor from pedido p inner join clientes c on (p.cliente=c.codigo);
Vamos executar o comando a seguir para verificar o entendimento do join e do alias.
Select f.nome, p.valor as pagamento from funcionarios f INNER JOIN pagamentos p ON
f.codigo_ funcionario = p.codigo_ funcionario;
select f.nome, p.valor as pagamento from funcionarios f LEFT JOIN pagamentos p ON
f.codigo_ funcionario= p.codigo_ funcionario;
ALIAS PARA TABELAS:

Quando usamos Join, o nome da tabela é citado para diferenciar a qual campo se está
fazendo referência. Quando a consulta é complexa e
envolve várias tabelas, referenciar o nome da tabela pode aumentar muito o tamanho
da consulta.
Para criar uma alias para uma tabela, basta acrescentar um identificador à frente
do nome da tabela. A partir de então, basta utilizar este alias
para se referenciar à tabela.
Select nome,nr,valor from pedido p inner join clientes c on (p.cliente=c.codigo);
TRIGGERS NO MYSQL:
Um trigger é um conjunto de instruções SQL para desempenhar funções lógicas em
banco de dados, como atualizar uma coluna estoque do
produto. Toda vez que houver uma venda de um item de produto, automaticamente pode
subtrair o item de venda do estoque, por meio de uma
configuração trigger na tabela de itens de venda.
Antes, podemos saber sobre triggers armazenadas, utilizando o comando SQL a seguir:
SELECT * FROM INFORMATION_SCHEMA.TRIGGERS;
Vamos, num primeiro momento, criar duas tabelas: uma de produto e outra de itens de
venda. Para isso, executamos os scripts a seguir, por
meio de queries. Recomenda-se seguir os seguintes passos na ordem em que são
citados os exemplos.
1. CRIAÇÃO TABELA PRODUTOS
CREATE TABLE Produtos (
Referencia INT PRIMARY KEY,
Descricao VARCHAR(50) UNIQUE,
Estoque INT NOT NULL DEFAULT 0);
2. INSERT TABELA PRODUTOS
INSERT INTO Produtos VALUES (1, ‘Feijão’, 10);
INSERT INTO Produtos VALUES (2, ‘Arroz’, 5);
INSERT INTO Produtos VALUES (3, ‘Farinha’, 15);
INSERT INTO Produtos VALUES (4, ‘SAL’, 15);
INSERT INTO Produtos VALUES (5, ‘ACUCAR’, 9);
INSERT INTO Produtos VALUES (6, ‘CAFE’, 12);
3. Apresentação dos dados da tabela PRODUTOS
Select * from produtos;
4. CRIAÇÃO TABELA itens de venda
CREATE TABLE itensvenda (
Venda INT NOT NULL,
Produto INT NOT NULL,
Quantidade INT NULL,
PRIMARY KEY (Venda, Produto));
5. CRIAÇÃO TRIGGER itens de venda para INSERT
Toda vez que incluir um item de venda, atualiza-se o valor de estoque do produto,
subtraindo do estoque do produto a quantidade de vendas.
DELIMITER $
CREATE TRIGGER Tgr_ItensVenda_Insert AFTER INSERT
ON ItensVenda
FOR EACH ROW
BEGIN
UPDATE Produtos SET Estoque = Estoque - NEW.Quantidade
WHERE Referencia = NEW.Produto;
END$
O nome da trigger é Tgr_ItensVenda_Insert. Após cada vez que for incluído um item
na tabela itens de venda (AFTER INSERT), será subtraída a
quantidade (NEW.Quantidade) do estoque (Estoque). Para cercar isso, a atualização
correta do registro é comparada à coluna Referência da
tabela produto com itens de produto (NEW.Produto). Após a criação do trigger, irá
aparecer dentro da tabela de vendas
6. INSERT DE ITENS DE VENDAS
Vamos incluir os itens de venda para ativar o trigger.
INSERT INTO ItensVenda VALUES (1, 1,3);
Após a inclusão de dados na tabela de ItensVenda, é mostrado o resultado da
consulta (conforme tabela 22). Após a inclusão, entra em ação o
Tgr_ItensVenda_Insert, que subtrai a quantidade de itens de vendas do estoque do
produto (10 – 3 = 7).
7. CRIAÇÃO DE TRIGGGER PARA TABELA ITENS DE VENDAS APÓS DELETE
Toda vez que excluir um item de venda, atualiza-se o valor de estoque do produto,
somando no estoque do produto a quantidade de vendas.
DELIMITER $
CREATE TRIGGER Tgr_ItensVenda_Delete AFTER DELETE
ON ItensVenda
FOR EACH ROW
BEGIN
UPDATE Produtos SET Estoque = Estoque + OLD.Quantidade
WHERE Referencia = OLD.Produto;
END$
O nome da trigger é Tgr_ItensVenda_Delete. Após cada vez que for excluído um item
na tabela itens de venda (AFTER DELETE), será somada a quantidade (OLD.Quantidade)
do estoque (Estoque). Para cercar isso, a atualização correta do registro é
comparada à coluna Referência da tabela produto com itens de produto (OLD.Produto).
Após a criação do trigger, irá aparecer dentro da tabela de vendas.
8. DELETE NA TABELA ITENS DE VENDAS
Vamos executar a exclusão do item de venda. Para ativar a trigger
“Tgr_ItensVenda_Insert” de exclusão do item de venda.
DELETE FROM itensvenda WHERE venda = 1 AND produto = 1;
Após a exclusão de dados na tabela de ItensVenda, é mostrado o resultado da
consulta
9. CONSULTA DA TABELA PRODUTOS
Após a exclusão do item de venda, entra em ação o Tgr_ItensVenda_Delete, que soma a
quantidade de itens de vendas do estoque do produto
(7 + 3 = 10).
“STORED PROCEDURE”:
A sintaxe geral para criação de Stored Procedure é a seguinte:
CREATE PROCEDURE proc_name([parameters, ...])
[characteristics]
[BEGIN]
corpo_da_rotina;
[END]
Detalhes sobre a configuração de parâmetros para sintaxe de “Stored Procedure”:
proc_name: seu procedimento armazenado deve ter um nome para, quando for chamado,
podermos então usá-lo.
tipo_param: existem três tipos de parâmetros em uma Stored Procedure.
proc_name: seu procedimento armazenado deve ter um nome para, quando for chamado,
podermos então usá-lo.
tipo_param: existem três tipos de parâmetros em uma Stored Procedure no MySQL:
a) IN – este é um parâmetro de entrada, ou seja, um parâmetro cujo valor será
utilizado no interior do procedimento para produzir algum resultado.
b) OUT – este parâmetro retorna algo de dentro do procedimento para o lado externo,
colocando os valores manipulados disponíveis na
memória ou no conjunto de resultados.
c) INOUT – faz os dois trabalhos ao mesmo tempo.
Para colocar em prática, vamos criar uma tabela “tbl_correntista”, conforme script
abaixo; o objetivo é criar uma Stored Procedure para passar
por parâmetros NOME e CPF, em que esses parâmetros são passados por uma chamada por
“CALL”, que é executado por query, na ferramenta
IDE WorkBench MySQL. A chamada por “CALL” ativa a “Stored Procedure” que, com os
parâmetros passados, é atualizada a tabela
tbl_correntista.
1. PRIMEIRO PASSO: Criação da tabela Correntista
CREATE TABLE tbl_correntista (
correntista_id int auto_increment primary key,
correntista_nome varchar(60) not null unique,
correntista_cpf varchar(20) not null,
dt_cadastro timestamp default current_timestamp);
2. SEGUNDO PASSO: Criação STORED PROCEURE para INSERT
Vamos criar a “STORED PROCEDURE” para criar incluir dados de parâmetros passados
pela chamada do “CALL” para incluir dados na tabela Correntista.
DELIMITER $
CREATE PROCEDURE mySp_correntistaInsert
(v_correntista_nome VARCHAR(60), v_correntista_cpf VARCHAR(20))
BEGIN
IF ((v_correntista_nome!= ‘’) && (v_correntista_cpf!= ‘’)) THEN
INSERT INTO tbl_correntista (correntista_nome, correntista_cpf)
VALUES (v_correntista_nome, v_correntista_cpf);
ELSE
SELECT ‘NOME e CPF devem ser fornecidos para o cadastro!’ AS Msg;
END IF;
END$
O nome da “Stored Procedure” é “mySp_correntistaInsert”. Após cada vez que for
acionada por uma chamada por “CALL”, será ativada a “Stored Procedure” e, então, é
efetivada a inclusão na tabela correntista.
Os parâmetros são recebidos nome (v_correntista_nome) e CPF (v_correntista_cpf).
Depois disso, são verificados se os parâmetros conteúdos não são vazios; então, é
efetivada a inclusão da tabela correntista por meio da instrução (INSERT INTO
tbl_correntista) e são incluídos os dados “VALUES (v_correntista_nome,
v_correntista_cpf)”.
3. TERCEIRO PASSO: Chamada da “Stored Procedure” por “CALL”
Antes da chamada é apresentada a consulta da tabela
A chamada de “CALL” da “Stored Procedure” é feita por query na ferramenta IDE
WorkBench MySQL, conforme a seguinte instrução:
CALL mySp_correntistaInsert (‘Wagner Bianchi’, ‘023.456.789-10’);
Após a chamada por “CALL” ativa a “Stored Procedure” e, então, a inclusão de dados
é providenciada e, depois disso, a tabela de correntista fica
com os dados.

Anotações Banco de Dados

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Anotações Banco de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

- Os conceitos de banco de dados e modelo entidade relacionamento: O banco de daos

surgiu da necessidade de guardar informações

- Estrutura de um sistema gerenciador de banco de dados (SGBD):

-Conceitos de modelagem de banco de dados:

-Conceitos e notações gráficas:

-Modelagem de banco de dados - Normalização:

-Modelagem de banco de dados - Conceitos de formas normais:

-Diagrama de entidade e relacionamento (DER) - Ferramenta case - Software Livre:

-MODELO LÓGICO E PROJETO FÍSICO DE BANCO DE DADOS:

-PROJETOS CONCEITUAL X LÓGICO X FÍSICO:

-RELACIONAMENTOS COM ENTIDADES:

-RELACIONAMENTOS COM ATRIBUTOS:

-IDENTIFICADOR ATRIBUTO CHAVE ÚNICA:

-EXEMPLO DE UM PROJETO LÓGICO NA TERCEIRA FORMA NORMAL:

-CONCEITOS DO PROJETO FÍSICO:

UTILIZAÇÃO DE COMANDOS SQL PARA CRIAÇÃO E MANUTENÇÃO DE DADOS:

CRIAÇÃO DE BANCOS DE DADOS:

Tipos de Alfanuméricos – Strings:

COMANDOS DE SQL PARA OPERAÇÕES AVANÇADAS DE BANCOS DE DADOS:

COMANDOS SQL GERAIS:

TABELAS PARA USO DOS EXEMPLOS A SEGUIR:

ALIAS PARA TABELAS:

Você também pode gostar