Você está na página 1de 71

DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS

Prof. Sérgio AGNELLO Pág. 1 de 71

 Conteúdo previsto de aulas


Qde
Sem Tópico Descrição
Aulas

Organização e Planejamento didático-pedagógico da disciplina. Elaboração dos instrumentos de


1 01 3
avaliação semestral.

Apresentação da disciplina, objetivos, conteúdo programático, bibliografia, critérios e sistema de


1 02 3
avaliação. Conceitos introdutórios.

Arquitetura dos SGBD: níveis externo, conceitual e interno. Linguagens utilizadas DML, DDL e DCL.
1 03 3
Apresentar gráfico do esquema geral da arquitetura do SGBD.

Modelagem conceitual de dados. Diagrama Entidade-Relacionamento. Apresentar a notação do


1 04 3
Peter Chen.

Modelagem conceitual de dados. Entidades. Atributos simples, compostos, multivalorados,


1 05 3
derivados.

1 06 3 Relacionamentos, cardinalidade (mínima e máxima).


Modelagem conceitual de dados. Entidade forte. Entidade fraca. Tipos de relacionamento (1:1, 1:n,
1 07 3
n:n).

1 08 3 Modelagem conceitual de dados. Exercícios em sala


1 09 3 Auto-relacionamento

1 10 3 Modelagem conceitual de dados. Exercícios em sala.


Modelagem conceitual de dados. Entidades associativas. Agregação. Generalização. Especialização
1 11 3
(total e parcial)

1 12 3 Modelagem conceitual de dados. Exercícios em sala.


1 13 3 Modelagem conceitual de dados. Exercícios em sala.

1 14 3 Modelo relacional. Derivação do modelo conceitual para o modelo lógico de dados.


1 15 3 Modelagem lógica. Exercícios em sala.

1 17 3 Modelagem lógica. Formas normais (até a 3° forma normal)


1 19 3 Modelagem lógica. Exercícios em sala de aula.

Organização e Planejamento didático-pedagógico da disciplina. Elaboração dos instrumentos de


2 23 3
avaliação semestral.

Modelo físico de dados. Introdução ao SQL. Definição das estruturas do banco de dados, utilizando
2 24 3
DDL

Modelo físico de dados. Regras de integridade: chave primária, chave estrangeira, domínios de
2 25 3
atributos.

2 26 3 Modelo físico de dados. Exercícios no laboratório.

2 28 3 Comandos de manipulação de dados (DML). Insert, Update e Delete.

Comandos de manipulação de dados (DML). Consultas simples, Where, Operadores lógicos e


2 29 3
aritméticos e Order By.

Comandos de manipulação de dados (DML). Consultas complexas, Funções agregadoras (max, min,
2 30 3
sum, avg, count), Group By, Distinct e Having

2 31 3 Comandos de manipulação de dados (DML). Exercícios no laboratório.

2 32 3 Comandos de manipulação de dados (DML). Subconsultas


2 33 3 Comandos de manipulação de dados (DML). Junções (joins) Internas (inner) , cross join.
2 34 3 Comandos de manipulação de dados (DML). Junções (joins) Externas (outer)

2 35 3 Comandos de manipulação de dados (DML). Exercícios no laboratório.

2 37 3 Índices: simples e compostos, clusterizados e não clusterizados, únicos e não únicos .

2 38 3 Conceitos de Visões (views). Conceitos de Stored procedures. Conceitos de Triggers.

2 39 3 Views, Stored procedures e Triggers. Exercícios no laboratório.

2 40 3 Gerenciamentos, Recuperação e Concorrência de transações.

2 41 3 Gerenciamentos, Recuperação e Concorrência de transações.


2 42 3 Avaliação da Coordenação (AC).
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 2 de 71

 O PROCESSO DE NORMALIZAÇÃO

14. MODELO DE DADOS RELACIONAL

14.1 NOTAÇÃO DE RELAÇÃO


O modelo relacional utiliza uma notação para representar estruturas de dados. Uma estrutura
de dados é a representação de uma classe de objetos, documentada sintaticamente por um
nome da classe e uma sequência de um ou mais nomes representativos dos atributos que
descrevem as características da classe sendo documentada. Por exemplo vamos pensar na
Classe de Objetos Alunos. Alunos é descrito por um conjunto de um ou mais atributos que
poderiam ser:
- Matrícula – que conterá o valor da matrícula de registro no aluno na instituição;
- Nome – que conterá o nome por extenso do aluno;
- DataNasc – que conterá a data de nascimento do aluno;
- Sexo – que conterá uma letra F para alunas e M para alunos; etc.

A Notação de Relação tem pequenas variações entre os diversos autores do mercado. Essas
diferenças são rapidamente percebidas e não devem representar um problema. Na apostila e
no curso iremos utilizar a NB (Notação Brasileira) que é a seguinte:

MODELO SIGNIFICADO
X (a;b) X consiste de uma ocorrência de valor para a e para b
X [a|b] X consiste, opcionalmente, de a ou b
X [a] X consiste opcionalmente de um valor para a
X {a;b} X consiste de no mínimo 0 e no máximo infinitas ocorrências de valor para a e b
X .y{a;b}z X consiste de no mínimo y e no máximo z ocorrências de valor para a e b
X consiste de no mínimo y e no máximo infinitas ocorrências de valor para a ,
X.y{a;[b|c]}
a e b ou a e c

OBSERVAÇÕES: ( ) = UMA OCORRENCIA; [ ] = OPCIONALIDADE; { } = VÁRIAS OCORRÊNCIAS DE


VALOR, ;= E e | = OU

14.2 O PROCESSO DE NORMALIZAÇÃO


MODELAGEM EM BANCO DE DADOS - NORMALIZAÇÃO
A Modelagem de Dados tem como objetivo encontrar a melhor proposta de armazenamento
dos dados que interessam a um determinado projeto computacional. É interesse do processo
de Modelagem eliminar as chamadas “falhas de armazenamento”, que se estabelecem tanto na
inclusão, atualização e/ou exclusão de novos dados na base de dados projetada. São
premissas da Modelagem de Dados:
- Não representa boa prática guardarmos coisas que não pretendemos utilizar depois.
Tudo que guardamos, devemos saber onde guardamos para, na hora
da necessidade, saibamos recuperá-las facilmente;
- Não representa boa prática produzirmos e mantermos registros
duplicados de uma mesma informação, pois nas discrepâncias não
saberemos qual a informação verdadeira e, para mantermos a
unicidade de informação, a cada alteração, quanto mais cópias
redundantes, maior o esforço realizado na atualização; e
- Aperfeiçoar o máximo a alocação prévia de espaço em mídia,
evitando a reserva desnecessária de espaço em disco para dados
eventuais, como por exemplo, o espaço pré reservado para um
conjunto de informações futuras que não sabemos previamente se TED CODD
irão se confirmar. A Normalização, como proposta de otimização de
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 3 de 71

estruturas de dados em projetos de Modelagem de Dados, foi introduzida em 1970 por Edgard
Frank (Ted) Codd, na época consultor da IBM, na especificação da 1ª.FN ou 1ª. Forma Normal,
utilizando os conceitos da teoria dos conjuntos – Álgebra Relacional. A proposta consiste em
aplicar uma série de regras sobre a estrutura de dados, candidata à constituição da base de
dados sendo projetada, de modo a eliminar as “falhas de organização dos dados”, já citadas,
que acabam afetando a qualidade e a performance nas operações de guarda, atualização e
recuperação dos dados armazenados.

Assim, os objetivos principais da Normalização são:


• Garantir a integridade dos dados, evitando que informações sem sentido sejam
mantidas;
• Organizar e dividir os arquivos ou tabelas da forma mais eficiente possível, diminuindo
a redundância e permitindo a evolução do banco de dados

14.3 CONCEITOS ESSENCIAIS

Determinação - Chaves
DF - Dependência Funcional
DP – Dependência Funcional Parcial
DT – Dependência Transitiva - Transitividade
Dependência Multivalorada
Trivialidade

14.4 CONCEITOS ADICIONAIS

DF – DEPENDÊNCIA FUNCIONAL IRREDUTÍVEL À ESQUERDA


O lado esquerdo de uma dependência funcional é irredutível à esquerda quando o
determinante está na sua forma mínima, não é possível reduzir a quantidade de atributos
determinantes sem perder a dependência funcional.
{cidade,estado}  país (Não está na forma irredutível à esquerda*)
* podemos ter somente o estado como determinante
Estado  país (Está na forma irredutível à esquerda)
NOTA: Nem sempre estar na forma irredutível à esquerda significa possuir um determinante
com apenas um atributo.

DEPENDÊNCIA MULTIVALORADA
O valor de um atributo determina um conjunto de valores de um outro atributo.
{CPF}  {nome} (um nome para cada CPF)
{CPF}  {dependente}(vários dependentes para cada CPF)
Uma dependência multivalorada é representada por:
X  Y (X multidetermina Y ou Y é multidependente de X)

14.5 ALGUNS SÍMBOLOS FAZEM PARTE DO MODELO RELACIONAL:

 = projeção, isto é, o(s) atributo(s) que antecede(m) a flecha é (são) refletido(s) na relação
indicada após a flecha;
 = junção, isto é, é (são) copiado/agrupados na relação, indicada antes da flecha, o(s)
atributo(s) relacionado(s) após a flecha; e
U = união, isto é, o(s) atributo(s) relacionado(s) antes do U é (são) agrupado(s) com o(s)
atributo(s) apontado(s) após o U.
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 4 de 71

14.6 DEPENDÊNCIAS FUNCIONAIS - DF

A Dependência Funcional (DF) é um dos conceitos fundamentais no desenho dos modelos de


dados relacionais. A Dependência Funcional é uma associação que se estabelece entre dois ou
mais atributos de uma relação e define-se do seguinte modo: Se A e B são atributos, ou
conjuntos de atributos, da relação R, diz-se que B é funcionalmente dependente de A se cada
um dos valores de A em R tem associado a si um e um só valor de B em R; a DF tem a
notação: A – B.
Com outras palavras, a Dependência Funcional – DF, também pode ser definida sim: dizemos
que o atributo B é funcionalmente dependente do atributo A, se para sabermos o valor do
atributo B em uma determinada linha da relação (tabela) R, precisamos declarar o valor que o
atributo A tem na mesma linha da relação R. Normalmente A é definido como Atributo
Determinante em R ou Primary Key (chave primária) em R.

Na Figura 14-5 é apresentada a notação gráfica relacionada com a dependência funcional. A


dependência funcional é representada por uma linha horizontal que parte do(s) atributo(s)
mais à esquerda, terminando com setas nos atributos dependentes, localizados à direita.
Todos os atributos que não fazem parte da chave primária de uma relação são funcionalmente
dependentes dela.

Figura 14-5: As dependências funcionais na relação "ESPÉCIE".

14.7 DEPENDÊNCIA (FUNCIONAL) PARCIAL - DP

A dependência funcional Parcial ou simplesmente Dependência Parcial (DP) é outro dos


conceitos fundamentais no desenho dos modelos de dados relacionais. A Dependência Parcial é
uma associação que se estabelece entre dois ou mais atributos de uma relação e define-se da
seguinte forma: Se A e B são atributos, ou conjuntos de atributos, da relação R, diz-se que B
é funcionalmente dependente de A se cada um dos valores de A em R tem associado a si um e
um só valor de B em R; a DF tem a notação: A - B

14.8 SUA EXCELÊNCIA O SGBDR:


SISTEMA GERENCIADOR DE BANCOS DE DADOS RELACIONAIS

Característica 1: Controle de Redundâncias - A redundância consiste no armazenamento


de uma mesma informação em locais diferentes, provocando inconsistências. Em um Banco de
Dados as informações só se encontram armazenadas em um único local, não existindo
duplicação descontrolada dos dados. Quando existem replicações dos dados, estas são
decorrentes do processo de armazenagem típica do ambiente Cliente-Servidor, totalmente sob
controle do Banco de Dados.

Característica 2: Compartilhamento dos Dados - O SGBD deve incluir software de controle


de concorrência ao acesso dos dados, garantindo em qualquer tipo de situação a escrita/leitura
de dados sem erros.
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 5 de 71

Característica 3: Controle de Acesso - O SGDB deve dispor de recursos que possibilitem


selecionar a autoridade de cada usuário. Assim um usuário poderá realizar qualquer tipo de
acesso, outros poderão ler alguns dados e atualizar outros e outros ainda poderão somente
acessar um conjunto restrito de dados para escrita e leitura.

Característica 4: Interfaceamento - Um Banco de Dados deverá disponibilizar formas de


acesso gráfico, em linguagem natural, em SQL ou ainda via menus de acesso, não sendo uma
"caixa-preta" somente sendo passível de ser acessada por aplicações.

Característica 5: Esquematização - Um Banco de Dados deverá fornecer mecanismos que


possibilitem a compreensão do relacionamento existentes entre as tabelas e de sua eventual
manutenção.

Característica 6: Controle de Integridade -Um Banco de Dados deverá impedir que


aplicações ou acessos pelas interfaces possam comprometer a integridade dos dados.

Característica 7: Backups - O SGBD deverá apresentar facilidade para recuperar falhas de


hardware e software, através da existência de arquivos de "pré-imagem" ou de outros
recursos automáticos, exigindo minimamente a intervenção de pessoal técnico.
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 6 de 71

NORMALIZAÇÃO – Case MCA II - Mapa Controle de Aulas II

 MCA II – Mapa Controle de Aulas II

MCA Data: ____/______/__________.

Matéria:
Código:_____ Nome: __________________________________ Carga Horária ________

Professor:
Código:_____ Nome: __________________________________ Telefone:____________

Alunos (1 – 50) Dias Letivos


Nota
Matrícula Nome DT1 DT2 DT3 ... ... ... ... DT10

Representando o Formulário MCA II por meio de Relação com base na Proposta Brasileira
de Notação de Relações:

MCA {CodMCA; DataMCA; Materia (CodMat; NomeMat; ChMat); Professor (CodProf; NomeProf;
TelProf); Alunos.1 {MatricAlu; NomeAlu; DiasLetivos.1{DT; Fi;}10; NotaAlu }50}

1ª FN (Projeção) dos Grupos de Repetição de Atributos, ou Pares de Chaves


internos, do mais externo para o mais interno, um par de cada vez.

MCA { CodMCA; DataMCA; Materia (CodMat; NomeMat; ChMat); Professor (CodProf; NomeProf;
TelProf ) }
AlunosDeMCA { CodMCA; MatricAlu; NomeAlu; DiasLetivos.1 {DT; Fi }10 ; NotaAlu}

Reaplicando a 1ª FN, agora no segundo conjunto de chaves (o mais interno).

MCA {CodMCA; DataMCA; Materia (CodMat; NomeMat; ChMat); Professor (CodProf; NomeProf;
TelProf ) }
AlunosDeMCA { CodMCA; MatricAlu; NomeAlu; NotaAlu}

DiasLetivosDeAlunosDeMCA { CodMCA; MatricAlu; DT; Fi;}


DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 7 de 71

2ª FN (Projeção) das Dependências Parciais (DP), só é aplicável em Relações de


Chave Composta – normalmente derivadas da Aplicação da 1ª FN.

Chamamos um atributo de DF – Dependente Funcional quando para sabermos o valor do


atributo, temos que saber o valor da chave toda (seja ela composta ou atômica (formada por
um único atributo))
Chamamos de Dependente Parcial todo atributo que para descobrirmos o seu valor só
precisamos saber o valor de apenas parte da chave. Se existir o DP, ele será projetado dando
origem a uma nova relação, formada pelo atributo determinante (Chave) que o identificou
mais o atributo DP.

Relações com Chave Composta após a 1ª FN


DPMatrAlu DF
AlunosDeMCA { CodMCA; MatricAlu; NomeAlu; NotaAlu}
DF
DiasLetivosDeAlunosDeMCA { CodMCA; MatricAlu; DT; Fi;}

Após a aplicação da 2ª FN teremos:


MCA {CodMCA; DataMCA; Materia (CodMat; NomeMat; ChMat); Professor (CodProf; NomeProf; TelProf ) }

AlunosDeMCA { CodMCA; MatricAlu; NotaAlu}

Alunos { MatricAlu; NomeAlu }

DiasLetivosDeAlunosDeMCA { CodMCA; MatricAlu; DT; Fi;}

3ª FN (Projeção) das Dependências Transitivas (DT), só aplicável nas relações


contendo pares de parêntesis internos.

A –– B –– C ( lê-se: C é DF-Dependente Funcional de B que é DF-Dependente Funcional de A)


DF DF
DT ( Logo C é DT-Dependente Transitivo de A)

DF = Dependência Funcional e DT = Dependência Transitiva


Se “A” é pai de “B” que é pai de “C” então “A” é avô de “C”
“C” é DF - dependente funcional de “B” que é DF – dependente funcional de “A”,
logo “C” é DT – dependente transitivo de “A”

Após a aplicação da 3ª FN teremos:


MCA { CodMCA; DataMCA; CodMat; CodProf }

Materias { CodMat; NomeMat; ChMat}

Professores { CodProf; NomeProf; TelProf ) }

AlunosDeMCA { CodMCA; MatricAlu; NotaAlu}

Alunos { MatricAlu; NomeAlu }

DiasLetivosDeAlunosDeMCA { CodMCA; MatricAlu; DT; Fi;}


DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 8 de 71

Criando o SCHEMA PLBD (DER)


MCA {CodMCA; DataMCA; CodMat; CodProf)

Matérias {CodMat; NomeMat; ChM}

Professores { CodProf; NomeProf; TelProf }

AlunosDeMCA {CodMCA; MatricAlu; Nota }

Alunos {MatricAlu; NomeAlu)

DiasLetivos {CodMCA; MatricAlu;DT; Fi;}

Representa apenas 1 ligação e representa N ligações.


Mostra o fluxo de dados do com ligação na chave “CodMCA”
Mostra o fluxo de dados do com ligação na chave “CodMat”
Mostra o fluxo de dados do com ligação na chave “CodProf”
Mostra o fluxo de dados do com ligação na chave “CodMCA” e “MatricAlu”
Mostra o fluxo de dados do com ligação na chave “MatricAlu”
Devemos colocar no centro do DER o Campo Chave com maior número de ligações, neste caso o
campo “MCA”

O SCHEMA PLBD
Utilizando esse método o SCHEMA LBD - Lógico de Banco de Dados (que no Modelo Peter
Cheniano é tratado como ME-R ou DE-R) ficará assim:

Professores
1

N
1 N 1 N
Matérias MCA DiasLetivos
1 N
N

N 1 1
AlunosMCA 1
Alunos
N
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 9 de 71

O MLA - Modelo Lógico de Armazenamento ou


MC - Modelo de Carga
Na sequência indicaremos no Schema o MLA - Modelo Lógico de Armazenamento, também
conhecido por MC ou Modelo de Carga, que define a ordem de criação das tabelas, que
corresponde, também, à ordem de carga, ou seja, o momento que podemos povoar cada
tabela, sem agredir as regras de integridade:

Na referência a seguir devemos entender o seguinte: Nas relações, o lado 1 é considerado


primário, ou seja, é prioritário e vem em primeiro lugar. O lado N é secundário e por isso vem
sempre depois do primário. Assim o mapeamento fica da seguinte forma:

MC 1

Professores
1

MC 1 MC 2 N MC 4
1 N 1 N
Matérias MCA DiasLetivos
1 N
N

N 1
MC 3 MC 1 1
AlunosDeMCA 1
Alunos
N

MC1 - As tabelas Professores, Matérias e Alunos devem ser criadas antes das demais e entre
elas não há uma ordem obrigatória. Podemos até pressupor que antes de alunos deverão ser
identificadas as Matérias a serem lecionadas, depois os Professores e por último os Alunos,
mas isso é um formosismo não percebível pelo SGBD.
MC2 - A tabela MCA é primária nas relações com AlunosDeMCA e com DiasLetivos e nas outras
relações que mantém, as tabelas primárias (Professores e Matérias) já foram indicadas.
MC3 - AlunosDeMCA, pois AlunosDeMCA é primária em relação a DiasLetivos.
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 10 de 71

O MAL - Mapa de Acesso Lógico ou MA - Mapa de Acesso


Na sequência indicaremos no Schema o MAL - Mapa de Acesso Lógico, também conhecido por
MA ou Mapa de Acesso, que define a ordem de Acesso das tabelas, de modo a ir recompondo
as informações que forma separadas para evitar as chamadas falhas de atualização.
Na referência a seguir, devemos pensar no seguinte: Que informações precisamos? Vamos
recompor o documento MCA. Assim, a primeira tabela que devemos acessar a MCA. A partir
dos dados de MCA podemos buscar, Matérias e depois Professores, sempre correspondentes ao
mesmo MCA. Na sequência AlunosDeMCA, depois Alunos para obtermos os demais dados de
Alunos e finalmente DiasLetivos. Assim o mapeamento fica da seguinte forma:

MC 1 MA 3

Professores
1

MC 1 MA 2 MC 2 N MA 1 MC 4 MA 6
1 N 1 N
Matérias MCA DiasLetivos
1 N
N

N 1
MC 3 MA 4 MC 1 1 MA 5
AlunosDeMCA 1
Alunos
N

MA1 - A tabela MCA é a base para o preenchimento do documento, assim é ela quem vai
comandar todos os demais acessos.
MA2 e MA3: Ente MA2 e MA3 não há realmente diferença e elas poderiam ter o mesmo índice
MA2. Na sequência as demais tabelas vão sendo acessadas em função da composição das
demais informações.
É importante verificar que as tabelas são mapeadas para o acesso em função do que se
pretende compor de informações, assim é comum termos um único MC - Mapa de Carga e
diversos MAs - Mapas de Acesso, sendo um para cada tela ou Relatório pretendido pela
Aplicação.
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 11 de 71

 A LINGUAGEM SQL:
STRUCTURED QUERY LANGUAGE

A Structered Query Language ou Linguagem de Consulta Estruturada nasceu no Departamento


de Pesquisas da IBM, 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.

A SQL apresenta uma série de comandos que permite a definição e administração das
estruturas e objetos de dados, chamada de DDL (Data Definition Language ou Linguagem de
Definição de Dados). A DDL tem nos comandos Create, Alter e Drop sua maior representação.
O comando Create, p.e. é destinado a criação de objetos de Banco de Dados como o próprio
Banco de Dados, as Tabelas que o compõe, as relações existentes entre as tabelas e outros
objetos relevantes para a organização do Banco de Dados.

Outra série de comandos constitui a DML (Data Manipulation Language ou Linguagem de


Manipulação de Dados), que como o próprio nome diz, tem o objetivo de definir e manter os
dados (valores) que povoam os objetos de Banco de Dados, como as tabelas reais, virtuais e
temporárias. Com esta série de comandos DML, podemos compor consultas, inserções,
exclusões e alterações de dados, em um ou mais registros de uma ou mais tabelas de maneira
simultânea. Entre os comandos mais representativos da série DML estão o Select, Insert,
Update e Delete.

Há ainda uma subclasse de comandos DML, a DCL (Data Control Language ou Linguagem de
Controle de Dados), que oferece comandos de controle de manipulação de dados como Grant e
Revoke. Estes comandos são importantes por garantirem uma função substancial dos SGBDs
que é a de controle de Integridade Relacional ou Referencial.

A Linguagem SQL tem como grandes virtudes sua capacidade de gerenciar índices, sem a
necessidade de controle individualizado de índice corrente, algo muito comum nas linguagens
de manipulação de dados do tipo registro a registro. Outra característica muito importante
disponível em SQL é sua capacidade de construção de visões, que são formas de visualizarmos
os dados na forma de listagens independente das tabelas e organização lógica dos dados.

Outra característica de fundamental importância na linguagem SQL é a capacidade de garantir


a qualidade da informação armazenada, principalmente a resultante de operações que alteram,
conjuntamente, diversas instâncias de dados e um ou mais ambientes colaborativos de Bancos
de Dados. Este tipo de operação envolvente, que influencia diversos componentes do banco de
dados ao mesmo tempo é denominado Transação. Podemos desejar cancelar uma série de
atualizações ou, então, fixá-las, definitivamente, por diversos motivos. Administramos esta
seqüência de atualizações por meio dos comandos Commit e Rollback, responsáveis por estas
facilidades.

Devemos notar que a linguagem SQL consegue implementar estas soluções, somente pelo fato
de estar baseada em Banco de Dados, que garantem por si mesmo a integridade das relações
existentes entre as tabelas e seus índices.
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 12 de 71

 Procedimentos para instalação do Monitor XAMPP


fonte: http://xampp.softonic.com.br/download#pathbar
1º. Acessar o link acima e proceder o download com save em uma área de guarda de arquivos
da disciplina;

2º. Clicar em RUN;

3º. Executar o arquivo: “SoftonicDonwloader47560.exe << dar ENTER >>

4º. No processo de download do XAMPP ler o contrato e aceitar << dar ENTER >>

5º. Desmarcar Softonic Toolbar e clicar no botão PRÓXIMO;

6º. Aguarde o Download do XAMPP;

7º. No quadro “XAMPP FOR WINDOWS” Definir o diretório a ser instalado o XAMPP. Você pode
deixar em branco, o diretório escolhido pelo XAMPP será o de seu nome: C:/XAMPP e clique no
botão INSTALL;

8º. Aguarde o XAMPP instalar o XAMPP Control Panel, o MySQL, o APACHE, e o restante do Kit
XAMPP;

9º. Será aberta uma tela DOS (comandos do DOS) por meio do qual será proposto o seguinte
diálogo:
Should I add shortcuts to the Start Menu / Desktop? (y/n): y << dar ENTER >>
Current directory does not match configured directory.
I must relocate the XAMPP path correctly, should I proceed?
(y/x=exit setup) = y << dar ENTER >>
Should I make a portable XAMPP without drive letters?
Note: - You should use drive letters, if you want use services.
- With USB sticks you must not use drive letters
- Your choice? N << dar ENTER >>

XAMPP is ready to use!

I have set the timezone in ‘php-ini’ and ‘my.ini’ to “America / São Paulo”
You should correct these values if my guess was wrong. Press return to continue.
Please choose (1-7/x): X << dar ENTER >>

10º. Dar duplo clique no ícone XAMPP Control Pane.


DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 13 de 71

 TELAS DO GERENCIADOR PHP MyADMIN


DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 14 de 71

 ENTRANDO NO MySQL

Setting environment for using XAMPP for Windows.

145270@SPASCHOAL_SFL C:\xampp
# cd mysql

145270@SPASCHOAL_SFL C:\xampp\mysql
# cd bin

145270@SPASCHOAL_SFL C:\xampp\mysql\bin
# mysql -u root -p
Enter password: ( deixado em branco + enter )
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.1.37 Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

 CRIANDO OS OBJETOS NO MYSQL

12.1.10 .CREATE DATABASE Sintaxe

{ CREATE DATABASE | SCHEMA } [IF NOT EXISTS ] db_name


[create_specification...]

create_specification:
[DEFAULT] CHARACTER SET [ =] charset
DEFAULT] | [ COLLATE = [ ] charset

CREATE DATABASE cria um banco de dados com o nome fornecido. Para usar esta
afirmação, é necessário o CREATE privilégio para o banco de dados.
CREATE SCHEMA é um sinônimo para CREATE DATABASE.

Um erro ocorre se o banco de dados existe e você não especificou Se não existir.

create_specification opções especificam características de banco de dados . características de


banco de dados são armazenados no db.opt arquivo no diretório do banco de dados. O
CHARACTER SET cláusula especifica o caractere banco de dados padrão definido. O
COLLATE cláusula especifica o agrupamento de banco de dados padrão.

Um banco de dados MySQL é implementado como um diretório contendo arquivos que


correspondem a tabelas no banco de dados . Como não existem tabelas em um banco de
dados quando ele é criado , o CREATE DATABASE declaração apenas cria um diretório sob
o diretório de dados MySQL e db.opt arquivo. Regras para nomes de banco de dados
admissível são dadas em Seção 8.2 , "Nomes de objeto de esquema ". Se um nome de
banco de dados contém caracteres especiais , o nome para o diretório de banco de dados
contém codificados versões dos personagens , como descrito no Secção 8.2.3,
"Mapeamento de identificadores de nomes de arquivo ".

Se você criar manualmente um diretório sob o diretório de dados (por exemplo, com mkdir), O
servidor considera um diretório de banco de dados e mostra-se na saída do SHOW
DATABASES.
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 15 de 71

 CRIANDO O BANCO DE DADOS DE NOME MAPAS


SETTING ENVIRONMENT FOR USING XAMPP FOR WINDOWS.

145270@SPASCHOAL_SFL C:\XAMPP
# CD MYSQL

145270@SPASCHOAL_SFL C:\XAMPP\MYSQL
# CD BIN

145270@SPASCHOAL_SFL C:\XAMPP\MYSQL\BIN
# MYSQL -U ROOT –P
ENTER PASSWORD: (DEIXADO EM BRANCO + ENTER)
WELCOME TO THE MYSQL MONITOR. COMMANDS END WITH ; OR \G.
YOUR MYSQL CONNECTION ID IS 2
SERVER VERSION: 5.1.37 SOURCE DISTRIBUTION

TYPE 'HELP;' OR '\H' FOR HELP. TYPE '\C' TO CLEAR THE CURRENT INPUT STATEMENT.

MYSQL> CREATE DATABASE MAPAS;


ERROR 1007 (HY000): CAN'T CREATE DATABASE 'MAPAS'; DATABASE EXISTS
MYSQL>

 EXCLUINDO O BANCO DE DADOS DE NOME MAPAS SE JÁ EXISTIR

{ DROP DATABASE | SCHEMA } [IF EXISTS ] db_name

Exclui um Banco de Dados inteiro, com todas as suas tabelas. Para usar esse comando é
necessário ter-se o privilégio DROP no Banco de Dados.

MYSQL> CREATE DATABASE MAPAS;


ERROR 1007 (HY000): CAN'T CREATE DATABASE 'MAPAS'; DATABASE EXISTS

MYSQL> DROP DATABASE MAPAS;


QUERY OK, 2 ROWS AFFECTED (0.16 SEC)

MYSQL>

 RECRIANDO O BANCO DE DADOS DE NOME MAPAS


MYSQL> CREATE DATABASE MAPAS;
ERROR 1007 (HY000): CAN'T CREATE DATABASE 'MAPAS'; DATABASE EXISTS
MYSQL> DROP DATABASE MAPAS;
QUERY OK, 2 ROWS AFFECTED (0.16 SEC)
MYSQL> USE MAPAS; --> SELECIONA O DATABASE A SER TRABALHADO
ERROR 1049 (42000): UNKNOWN DATABASE 'MAPAS'
MYSQL> CREATE DATABASE MAPAS; --> CRIA O DATABASE MAPAS NOVAMENTE
QUERY OK, 1 ROW AFFECTED (0.00 SEC)
MYSQL> USE MAPAS;
DATABASE CHANGED
MYSQL>
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 16 de 71

 TIPOS DE DADOS
Depois de criar a base de dados, e uma vez as relações normalizadas, é necessário criar as
tabelas correspondentes dentro da base de dados Mapas. Para cada campo de cada uma da
tabelas, é necessário determinar o tipo de dados que contem, para poder ajustar a estrutura
da base de dados, e conseguir um armazenamento com a menor utilização de espaço.

Os tipos de dados que pode ter um campo, podem-se agrupar em três grandes grupos:

1. Tipos numéricos
2. Tipos de Data
3. Tipos de Cadeia

1 Numéricos:

Existem tipos de dados numéricos, que se podem dividir em dois grandes grupos, os que estão
em vírgula flutuante (com decimais) e os que não.

TinyInt: é um número inteiro com ou sem signo. Com signo a margem de valores válidos é
desde -128 até 127. Sem signo, a margem de valores é de 0 até 255

Bit ou Bool: um número inteiro que pode ser 0 ou 1.

SmallInt: número inteiro com ou sem signo. Com signo a margem de valores válidos é desde
-32768 até 32767. Sem signo, a margem de valores é de 0 até 65535.

MediumInt: número inteiro com ou sem signo. Com signo a margem de valores válidos é
desde -8.388.608 até 8.388.607. Sem signo, a margem de valores é de 0 até 16777215.

Integer, Int: número inteiro com ou sem signo. Com signo a margem de valores válidos é
desde -2147483648 até 2147483647. Sem signo, a margem de valores é de 0 até
429.496.295

BigInt: número inteiro com ou sem signo. Com signo a margem de valores válidos é desde -
9.223.372.036.854.775.808 até 9.223.372.036.854.775.807. Sem signo, a margem de
valores é de 0 até 18.446.744.073.709.551.615.

Float: número pequeno em vírgula flutuante de precisão simples. Os valores válidos vão desde
-3.402823466E+38 até -1.175494351E-38,0 eté desde 175494351E-38 até
3.402823466E+38.

xReal, Double: número em vírgula flutuante de dupla precisão. Os valores permitidos vão
desde -1.7976931348623157E+308 até -2.2250738585072014E-308, 0 e desde
2.2250738585072014E-308 até 1.7976931348623157E+308

Decimal, Dec, Numeric: Número em vírgula flutuante desempacotado. O número armazena-


se como uma cadeia.

O MySQL 5.0 suporta todos os tipos de dados padrão SQL. Todos os tipos supracitados são
tipos de dados aceitos e podem ter muitos outros sinônimos - palavra que tem exatamente o
mesmo sentido que outra ou quase idêntico. O que temos que ter ciência também é quanto de
espaço por valor é requerido por cada tipo. Tais especificações são expostas na Tabela 1.
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 17 de 71

Tabela 1 - Tipos Numéricos

Tipos Numéricos

MySQL suporta todos os tipos numéricos da ANSI/ISO SQL92. Estes tipos incluem o tipos de
dados numéricos exatos (NUMERIC, DECIMAL, INTEGER, e SMALLINT), assim como o
tipos de dados numéricos aproximados (FLOAT, REAL, e DOUBLE PRECISION). A palavra-
chave INT é um sinônimo para INTEGER, e a palavra-chave DEC é um sinônimo para
DECIMAL.

Os tipos NUMERIC e DECIMAL são implementados como o mesmo tipo pelo MySQL, como
permitido pelo padrão SQL92. Eles são usados por valores para os quais é importante
preservar a exatidão como, por exemplo, dados monetários. Quando é declarado um campo de
algum desses tipos a precisão e a escala podem ser (e normalmente é) especificadas; por
exemplo:

salario DECIMAL(5,2)

Neste exemplo, 5 (precisão) representa o número de digitos decimais significantes que serão
armazenados no valor, e 2 (escala) representa o número de dígitos que serão armazenados
após o ponto decimal. Neste caso, no entanto, a faixa de valores que podem ser armazendos
na coluna salario é de -99.99 a 99.99. (MySQL pode, na verdade, armazenar numeros acima
de 999.99 neste campo porque ele não precisa armazenar o sinal para números positivos).

Em ANSI/ISO SQL92, a sintaxe DECIMAL(p) é equivalente a DECIMAL(p,0). Da mesma


forma, a sintaxe DECIMAL é equivalente a DECIMAL(p,0), onde a implementação permite
decidir o valor de p. MySQL ainda não suporta nenhuma dessas duas formas variantes dos
tipos de dados DECIMAL/NUMERIC. Este, geralmente, não é um problema sério, já que os
principais benefícios destes tipos derivam da habilidade de controlar precisão e escala
explicitamente.

Valores DECIMAL e NUMERIC são armazenados como strings, ao invés de um número de


ponto-flutuante binário, para preservar o precisão decimal destes valores. Um caracter é usado
para cada digito, para o ponto decimal (se escala > 0), e para o sinal ‘-’ (para números
negativos). Se escala é 0, valores DECIMAL e NUMERIC não contém ponto decimal ou parte
fracionária.

A faixa máxima dos valores DECIMAL e NUMERIC é o mesmo do DOUBLE, mas a faixa real
para um campo DECIMAL or NUMERIC pode ser limitado pela precisão ou pela escala para
uma dada coluna. Quando é atribuído a uma coluna um valor com mais digitos após o ponto
decimal do que o permitido especificado na escala, o valor é arredondado para aquela escala.
Quando é atribuido um valor a uma coluna DECIMAL ou NUMERIC o qual excede a faixa
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 18 de 71

determinada pelas precisão e escala especificada (ou padrão), MySQL armazena o valor
correspondente ao final daquela faixa.

Como uma extensão do padrão ANSI/ISO SQL92, MySQL também suporta os tipos integrais
TINYINT, MEDIUMINT, e BIGINT como listado nas tabelas abaixo. Outra extensão
suportada pelo MySQL é especificar, opcionalmente, o tamanho do display de um valor inteiro
entre parenteses seguindo o nome do tipo (por exemplo, INT(4)). Esta especificação opcional
do tamanho é usada para preenchimento a esquerda do display de valores cujo tamanho é
menor que o especificado para a coluna, mas não limita a faixa de valores que podem ser
armazendos na coluna, nem o número de dígitos que serão mostrados para valores que
excederem o tamanho especificado na coluna. Quando usados em conjunto com o atributo
opcional de extensão ZEROFILL, o padrão do preenchimento de espaços é a substituição por
zeros. Por exemplo, para uma coluna declarada com INT(5) ZEROFILL, o valor 4 é retornado
como 00004. Note que se você armazenar valores maiores que a largura do display em um
coluna do tipo inteiro, você pode ter problemas quando o MySQL gerar tabelas temporárias
para algum join complicado, já que nestes casos o MySQL acredita que os dados cabem na
largura original da coluna.

Todos os tipos inteiros podem ter um atributo opcional (não-padrão) UNSIGNED. Valores sem
sinal podem ser usados quando você permite apenas números positivos em uma coluna e você
precisa de uma faixa de valores um pouco maior para a coluna.

Desde o MySQL 4.0.2, tipos de ponto flutuante também podem ser sem sinal (UNSIGNED).
Como no tipos inteiros, este atributoprevine que valores negativos sejam armazenados na
coluna. Ao contrário dos tipos negativos, o valor máximo da faixa permitida permanece o
mesmo.

O tipo FLOAT é usado para representar tipos de dados numéricos aproximados. O padrão
SQL-92 permite uma especificação opcional da precisão (mas não da faixa do expoente) em
bits, após a a palavra FLOAT e entre parenteses. A implementação MySQL também suporta
esta especificação opcional de precisão. Quando FLOAT é usada para uma tipo de coluna sem
especificação de precisão, MySQL utiliza quatro bytes para armazenar os valores. Uma sintaxe
variante também é suportada, com dois numeros entre parenteses após a palavra FLOAT.
Com esta opção, o primeiro número continua a representar a quantidade de bytes necessária
para armazenar o valor, e o segundo número especifica o número de dígitos a serem
armazenados e mostrados após o ponto decimal (como com DECIMAL e NUMERIC). Quando
é pedido ao MySQL para armazenar um número em uma coluna com mais digitos decimais
após o ponto decimal que o especificado para esta coluna, o valor é arredondado eliminando
os digitos extras quando armazenado.

Os tipos REAL e DOUBLE PRECISION não aceitam especificações de precisão. Como uma
extensão do padrão SQL-92, o MySQL reconhece DOUBLE como um sinônimo para o tipo
DOUBLE PRECISION. Em constraste com a exigencia do padrão de que a precisão do tipo
REAL seja menor que aquele usado pelo DOUBLE PRECISION, MySQL implementa ambos
como valores de ponto flutuante de 8 bits de dupla precisão (quando não estiver executando
em ``modo ANSI''). Para uma portabilidade máxima, códigos que requerem armazenamento
de valores de dados numéricos aproximados usam FLOAT ou DOUBLE PRECISION sem
especificação de precisão ou de numeros decimais.

Quando solicitado a armazenar um valor em uma coluna numérica que está fora da faixa
permitida pelo tipo da coluna, o MySQL ajusta o valor ao limite da faixa permitida mais
apropriado e armazena este valor.

Por exemplo, a faixa de uma coluna INT é de -2147483648 a 2147483647. Se você tentar
inserir -9999999999 em uma coluna INT, o valor é ajustado para o limite mais baixo da
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 19 de 71

faixa de valores e -2147483648 é armazenado. Da mesma forma, se você tentar inserir


9999999999, 2147483647 será armazenado.

Se o campo INT é UNSIGNED, o tamanho da faixa do campo é o mesmo mas o limite passa a
ser de 0 a 4294967295. Se você tentar armazenar -9999999999 e 9999999999, os
valores armazenados na coluna serão 0 e 4294967296.

Conversões que ocorrem devido a ajustes são relatados como ``avisos'' para ALTER TABLE,
LOAD DATA INFILE, UPDATE, e instruções INSERT multi-registros.

Tipo Bytes De Até


TINYINT 1 -128 127
SMALLINT 2 -32768 32767
MEDIUMINT 3 -8388608 8388607
INT 4 -2147483648 2147483647
BIGINT 8 -9223372036854775808 9223372036854775807

This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The
original Reference Manual is in English, and this translation is not necessarily as up to date as
the English version.

2 Data:

Na hora de armazenar datas, há que ter em conta que MySQL não verifica de uma maneira
estricta se uma data é válida ou não. Simplesmente comprova que o mês está compreendido
entre 0 e 12 e que o dia está compreendido entre 0 e 31.

Date: tipo data, armazena uma data. A margem de valores vai desde o 1 de Janeiro de 1001
ao 31 de dezembro de 9999. O formato de armazenamento é de ano-mes-dia.

DateTime: Combinação de data e hora. A margem de valores vai desde o 1 ed Janeiro de


1001 às 0 horas, 0 minutos e 0 segundos ao 31 de Dezembro de 9999 às 23 horas, 59
minutos e 59 segundos. O formato de armazenamento é de ano-mes-dia
horas:minutos:segundos

TimeStamp: Combinação de data e hora. A margem vai desde o 1 de Janeiro de 1970 ao ano
2037. O formato de armazenamento depende do tamanho do campo:

Time: armazena uma hora. A margem de horas vai desde -838 horas, 59 minutos e 59
segundos. O formato de armazenamento é 'HH:MM:SS'.

Year: armazena um ano. A margem de valores permitidos vai desde o ano 1901 ao ano 2155.
O campo pode ter tamanho dois ou tamanho 4 dependendo de se queremos armazenar o ano
com dois ou quatro algarismos.

Tipo de Campo Tamanho de Armazenamento


DATE 3 bytes
DATETIME 8 bytes
TIMESTAMP 4 bytes
TIME 3 bytes
YEAR 1 byte
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 20 de 71

3 Cadeia:

Char(n): armazena uma cadeia de longitude fixa. A cadeia poderá conter desde 0 até 255
caracteres.

VarChar(n): armazena uma cadeia de longitude variável. A cadeia poderá conter desde 0 até
255 caracteres. Dentro dos tipos de cadeia pode-se distinguir dois subtipos, os tipo Test e os
tipo Blob (Binary Large Object) A diferença entre um tipo e outro é o tratamento que recebem
na hora de ordená-los e compará-los. No tipo test ordena-se sem ter importância as
maiúsculas e as minúsculas e no tipo blob ordena-se tendo em conta as maiúsculas e
minúsculas.

Os tipos blob utilizam-se para armazenar dados binários como podem ser ficheiros.

TinyText e TinyBlob: Coluna com uma longitude máxima de 255 caracteres.

Blob e Text: um texto com um máximo de 65535 caracteres.

MediumBlob e MediumText: um texto com um máximo de 16.777.215 caracteres.

LongBlob e LongText: um texto com um máximo de caracteres 4.294.967.295. Há que ter


em conta que devido aos protocolos de comunicação os pacotes podem ter um máximo de 16
Mb.

Enum: campo que pode ter um único valor de uma lista que se especifica. O tipo Enum aceita
até 65535 valores diferentes.

Set: um campo que pode conter nenhum, um ou vários valores de uma lista. A lista pode ter
um máximo de 64 valores.

Tipo de campo Tamanho de Armazenamento


CHAR(n) n bytes
VARCHAR(n) n +1 bytes
TINYBLOB, TINYTEXT Longitude+1 bytes
BLOB, TEXT Longitude +2 bytes
MEDIUMBLOB, MEDIUMTEXT Longitude +3 bytes
LONGBLOB, LONGTEXT Longitude +4 bytes
ENUM('value1','value2',...) 1 ó dos bytes dependendo do número de valores
SET('value1','value2',...) 1, 2, 3, 4 ó 8 bytes, dependendo do número de valores

Diferença de armazenamento entre os tipos Char e VarChar

Valor CHAR(4) Armazenamento VARCHAR(4) Armazenamento


'' '' 4 bytes " 1 byte
'ab' 'ab ' 4 bytes 'ab' 3 bytes
'abcd' 'abcd' 4 bytes 'abcd' 5 bytes
'abcdefgh' 'abcd' 4 bytes 'abcd' 5 bytes
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 21 de 71

Quadro Tipos de Dados Numéricos


TIPO INTERVALO bytes DESCRIÇÃO
-127 a 128; ou
TINYINT[(M)] 1 inteiros muitos pequenos
0 a 255
BIT o mesmo que TINYINT
BOOL o mesmo que TINYINT
SMALLINT[(M)] -32768 a 32767 2 inteiros pequenos
-8388608 a 8388607; ou
MEDIUMINT[(M)] 3 inteiros de tamanho médio
0 a 16777215
-213 a 231-1; ou
INT[(M)] 4 inteiros regulares
0 a 232-1
INTEGER[(M)] o mesmo que INT
-2 a 2 -1; ou
63 63
BIGINT[(M)] 8 inteiros grandes
0 a 264-1
números de ponto flutuante de
FLOAT(precisão) depende da precisão variável
precisão simples ou dupla
números de ponto flutuante de
1.175494351E-38 a
FLOAT[(M,D)] 4 precisão simples. O mesmo que
±3.402823466E+38
FLOAT(4)
±1.7976931348623157E+308 números de ponto flutuante de
DOUBLE[(M,D)] a ±2.2250738585072014E- 8 precisão dupla. O mesmo que
308 FLOAT(8)
DOUBLE O mesmo que DOUBLE[(M,D)]
PRECISION[(M,D)] O mesmo que DOUBLE[(M,D)]
REAL[(M,D)] O mesmo que DOUBLE[(M,D)]
número de ponto flutuante
DECIMAL[(M,D)] variável M+2
armazenado como char
NUMERIC[(M,D)] O mesmo que DECIMAL
DEC[(M,D)] O mesmo que DECIMAL

OBSERVAÇÕES:
 as opções entre colchetes ( [ e ]) são opcionais;
 dentre os tipos que se ajustam aos dados a serem inseridos, escolha sempre o de
menor tamanho;
 para dados do tipo inteiro você pode usar a opção UNSIGNED para especificar inteiros
positivos ou zero;
 M especifica o tamanho máximo de exibição;
 D especifica o número de casas decimais. O valor máximo de D é 30 ou M-2;
 tanto para números inteiros como para números de ponto flutuante você pode
especificar a opção ZEROFILL que preenche os números com zeros iniciais. Colunas
especificadas com ZEROFILL são automaticamente configuradas como UNSIGNED;
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 22 de 71

Quadro Tipos de Dados Data/Hora


TIPO INTERVALO DESCRIÇÃO
DATE 1000-01-01 a 9999-12-31 data. Exibido como YYYY-MM-DD
TIME -838:59:59 a 838:59:59 hora. Exibido como HH:MM:SS
1000-01-01 00:00:00 a data e hora. Exibido como YYYY-MM-DD
DATETIME
9999-12-31 23:59:59 HH:MM:SS
registro de data e hora útil para transações. Os
formatos de exibição podem ser:
TIMESTAMP YYYYMMDDHHMMSS
1970-01-01 00:00:00 a TIMESTAMP(14) YYYYMMDDHHMMSS
algum momento em 2037. TIMESTAMP(12) YYMMDDHHMMSS
TIMESTAMP[(M)]
Depende do limite do TIMESTAMP(10) YYMMDDHHMM
sistema operacional TIMESTAMP(8) YYYYMMDD
TIMESTAMP(6) YYMMDD
TIMESTAMP(4) YYMM
TIMESTAMP(2) YY
YEAR[(2)] 70 a 69 (1970 a 2069) ano
YEAR[(4)] 1901 a 2155 ano

Quadro Tipos de Dados String


TIPO INTERVALO DESCRIÇÃO
string de comprimento fixo M. NATIONAL
especifica que o conjunto de caracteres
padrão (ANSI SQL) será utilizado. BINARY
[NATIONAL] CHAR(M)
0 a 255 caracteres especifica que os dados devem ser tratados
[BINARY]
de modo a não haver distinção entre
maiúsculas e minúsculas (o padrão é
distinguir).
CHAR 1 o mesmo que CHAR(1)
[NATIONAL] 1 a 255 string de comprimento variável
VARCHAR(M) string de tamanho variável. O mesmo que
variável
[BINARY] [BINARY].
TINYBLOB 0 a 28 - 1 (255) BLOB pequeno
TINYTEXT 0 a 28 - 1 (255) TEXT pequeno
16
BLOB 0 a 2 - 1 (65535) BLOB normal
TEXT 0 a 216 - 1 (65535) TEXT normal
24
MEDIUMBLOB 0 a 2 - 1 (16777215) BLOB médio
24
MEDIUMTEXT 0 a 2 - 1 (16777215) TEXT médio
LONGBLOB 0 a 232 - 1 (4294967295) BLOB longo
32
LONGTEXT 0 a 2 - 1 (4294967295) TEXT longo
ENUM('valor1','valor2',...) 0 a 65535 armazenam um dos valores listados ou NULL
armazenam um ou mais dos valores listados
SET('valor1','valor2',...) 0 a 64
ou NULL
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 23 de 71

OBSERVAÇÕES:

 CHAR e VARCHAR armazenam strings de comprimento fixo e variável


respectivamente. VARCHAR trabalha mais lento.
 TEXT e BLOB armazenam textos grandes ou objetos binários (figuras, som, etc.). TEXT
diferencia maiúsculas de minúsculas.

AS TABELAS DO CASE MCA II


Por ordem de criação.

Tabela Materias – Primária – C1


CodMat Nr Inteiro, Não Nulo, Chave Primária,
NomeMat Texto (30),
ChMat Nro Inteiro Curto(Small),

Tabela Professores – Primária – C1


CodProf Nr Inteiro, Não Nulo, Chave Primária,
NomeProf Texto (30)
TelProf Texto (15)

Tabela Alunos – Primária – C1


MatricAlu Nr Inteiro, Não Nulo, Chave Primária,
NomeAlu Texto (30)

Tabela MCA – Secundária – C2


CodMCA Nr Inteiro, Não Nulo, Chave Primária,
DataMCA data, Formato yyyy-mm-dd,
CodMat Nr Inteiro, Não Nulo, Chave Estrangeira (Foreign Key),
CodProf Nr Inteiro, Não Nulo, Chave Estrangeira (Foreign Key),

Tabela AlunosDeMCA – Secundária – C3


CodMCA Nr Inteiro, Não Nulo, Chave Primária,
MatricAlu Nr Inteiro, Não Nulo, Chave Primária,
NotaAlu Nr Decimal(4,2)

Tabela DiasLetivosDeAlunosDeMCA – Secundária – C4


CodMCA Nr Inteiro, Não Nulo, Chave Primária,
MatricAlu Nr Inteiro, Não Nulo, Chave Primária,
DT Data, Não Nulo, Chave Primária,
Fi bool (verdadeiro ou falso)
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 24 de 71

 CRIANDO TABELAS NO DATABASE MAPAS


Criando as tabelas, onde os dados serão armazanados.
A síntese de criação de tabelas do MySQL é a seguinte:

CREATE [TEMPORARY] TABLE [IF NOT EXISTS] nome_tabela [(definição_create,...)]


[table_options] [select_statement]

Novamente podemos nos valer do parâmetro opcional IF NOT EXISTS para executarmos o
comando sem termos certeza da existencia ou não da tabela.
Para criarmos uma tabela bastaríamos executar a seguinte parte da síntese: CREATE TABLE
nome_tabela.

Mas é mais comum criarmos a tabela já acompanhada de seus campos (fields). Vejamos o
exemplo que cria a tabela filmes com os seguintes campos:
id - campo de identificação;
titulo - titulo do filme;
ano - Ano de produção;
diretor - diretor do filmes;
Para isto devemos executar o seguinte comando:

MYSLQ> CREATE TABLE FILMES (


ID INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
TITULO VARCHAR(80) NOT NULL,
ANO INT(4) UNSIGNED NOT NULL,
DIRETOR VARCHAR(80) NOT NULL,
PRIMARY KEY (ID));
QUERY OK, 0 ROWS AFFECTED (0.14 SEC)
MYSQL>

 DEFININDO OS CAMPOS DA TABELA SENDO CRIADA


Os campos são definidos da seguinte forma:

nome_campo tipo [ NULL | NOT NULL ] [ DEFAULT valor_padrão] [ AUTO_INCREMENT ]

No campo id por exemplo o tipo é int(10) com o modificador unsigned, ele não aceita valores
nulos (not null) e é auto_increment, ou seja, seu valor é definido automaticamente,
aumentando de 1 (um) em 1 (um) toda vez que um novo registro é adicionado. Para fazer uso
desta funcionalidade é necessário adicionar o valor 0 ou null neste campo.

No campo titulo escolhemos o tipo varchar(80) o que significa que este campo aceita
caracteres alfanuméricos num máximo determinado por nós de 80. O campo também não
pode ser nulo.
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 25 de 71

Restrições FOREIGN KEY


A partir da versão 3.23.43b, o InnoDB disponibiliza restrições de chaves estrangeiras. O
InnoDB é o primeiro tipo de tabela da MySQL, que permite definir restrições de chaves
estrangeiras para guardar a integridade dos seus dados.

A sintaxe da definição das restriçõess de chaves estrangeiras no InnoDB:

[CONSTRAINT [symbol]] FOREIGN KEY (index_col_name, ...)


REFERENCES nome_tabela (index_nome_coluna, ...)
[ON DELETE {CASCADE | SET NULL | NO ACTION
| RESTRICT}]
[ON UPDATE {CASCADE | SET NULL | NO ACTION
| RESTRICT}]

Ambas as tabelas devem ser do tipo InnoDB, na tabela deve existir um índice onde as colunas
de chaves estrangeiras listadas como as PRIMEIRAS colunas e na tabela indicada deve haver
um índice onde as colunas indicadas são listadas como as PRIMEIRAS colunas e na mesma
ordem. O InnoDB não cria índices automaticamente em chaves estrangeiras para chaves
referênciadas: você tem que criá-las explicitamente. Os índices são necessários para
verificação de chaves estrangeiras para ser rápido e não exigir a varredura da tabela.

Colunas correspondentes nas chaves estrangeiras e a chave referenciada devem ter tipos de
dados internos parecidos dentro do InnoDB para que possam ser comparados sem uma
conversão de tipo. O tamanho e a sinalização de tipos inteiros devem ser o mesmo. O
tamanho do tipos string não precisam ser o mesmo. Se você especificar uma ação SET NULL,
esteja certo de que você não declarou as colunas na tabela filha como NOT NULL.

Se o MySQL retornar o erro de número 1005 de uma instrução CREATE TABLE, e a string de
mensagem de erro se referir ao errno 150, então a criação da tabela falhou porque um
restrição de chaves estrangeiras não foi formada corretamente. Similarmente, se uma ALTER
TABLE falhar e se referir ao errno 150, sgnifica que um definição de chave estrangeira foi
formada incorretamente na tabela alterada. A partir da versão 4.0.13, você pode usar SHOW
INNODB STATUS para ver uma explicação detalhada do ultimo erro de chave estrangeira do
InnoDB no servidor.

A partir de versão 3.23.50, InnoDB não verifica restrições de chaves estrangeiras naqueles
valores de chaves estrangeiras ou chaves referênciadas que contenham uma coluna NULL.

Um desvio do padrão SQL: se na tabela pai existirem diversos registros têm o mesmo valor
de chave referência, então o InnoDB atua na verificação da chave estrangeira como o outro
registro pai como se o mesmo valor de chave não existisse. Por exemplo, se você tiver
definido uma restrição de tipo RESTRICT, e existir um registro filho com diversos registros
pais, o InnoDB não permite a deleção de qualquer um dos registros pais.

A partir da versão 3.23.50, você também pode associar a cláusula ON DELETE CASCADE ou
ON DELETE SET NULL com a restrição de chave estrangeira. Opções correspondentes do ON
UPDATE estão disponíveis a partir da versão 4.0.8. Se ON DELETE CASCADE for
especificado, e um registro na tabela pai for deletado, então o InnoDB automaticamente
também deleta todos aqueles registros na tabela filha cujos valores de chaves estrangeiras são
iguais ao valor da chave referênciada no registro pai Se ON DELETE SET NULL for
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 26 de 71

especificado, os registros filhos são automaticamente atualizados e assim as colunas na chave


estrangeira são definidas com o valor NULL do SQL.

Um desvio dos padrões SQL: se ON UPDATE CASCADE ou ON UPDATE SET NULL retornam
para atualizar a MESMA TABELA que ja tenha sido atualizada durante o processo cascata, ele
atua como RESTRICT. Isto é para prevenirloops infinitos resultantes de atualizações em
cascata. Um ON DELETE SET NULL auto referêncial, por outro lado, funciona desde a versão
4.0.13. ON DELETE CASCADE auto referêncial já está funcionando.

Um exemplo:

CREATE TABLE parent(id INT NOT NULL, PRIMARY KEY (id)) TYPE=INNODB;
CREATE TABLE child(id INT, parent_id INT, INDEX par_ind (parent_id),
FOREIGN KEY (parent_id) REFERENCES parent(id)
ON DELETE SET NULL
) TYPE=INNODB;

Um exemplo complexo:

CREATE TABLE product (category INT NOT NULL, id INT NOT NULL,
price DECIMAL,
PRIMARY KEY(category, id)) TYPE=INNODB;
CREATE TABLE customer (id INT NOT NULL,
PRIMARY KEY (id)) TYPE=INNODB;
CREATE TABLE product_order (no INT NOT NULL AUTO_INCREMENT,
product_category INT NOT NULL,
product_id INT NOT NULL,
customer_id INT NOT NULL,
PRIMARY KEY(no),
INDEX (product_category, product_id),
FOREIGN KEY (product_category, product_id)
REFERENCES product(category, id)
ON UPDATE CASCADE ON DELETE RESTRICT,
INDEX (customer_id),
FOREIGN KEY (customer_id)
REFERENCES customer(id)) TYPE=INNODB;

A partir da versão 3.23.50 o InnoDB lhe permite adicionar novas restriçoões de chaves
estrangeiras a uma tabela.

ALTER TABLE seunomedetabela


ADD [CONSTRAINT [symbol]] FOREIGN KEY (...) REFERENCES anothertablename(...)
[on_delete_and_on_update_actions]

LEMBRE-SE DE CRIAR OS ÍNDICES NECESSÁRIOS PRIMEIRO.

A partir da versão 4.0.13, o InnoDB suporta

ALTER TABLE suatabela DROP FOREIGN KEY id_chave_estrangeira_gerada_internamente


DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 27 de 71

Você tem que usar SHOW CREATE TABLE para daterminar as id's de chaves estrangeiras
geradas internamente quando você apaga uma chave estrangeira.

Na versão anterior a 3.23.50 do InnoDB, ALTER TABLE ou CREATE INDEX não devem ser
usadas em conexões com tabelas que têm restrições de chaves estrangeiras ou que são
referênciadas em restrições de chaves estrangeiras: Qualquer ALTER TABLE remove todas as
restrições de chaves estrangeiras definidas na tabela. Você não deve utilizar ALTER TABLE
para tabela referenciadas também, mas utilizar DROP TABLE e CREATE TABLE para modifcar
o esquema. Quando o MySQL faz um ALTER TABLE ele pode usar internamente RENAME
TABLE, e isto irá confundir a restrição de chave estrangeira que se refere a tabela. Uma
instrução CREATE INDEX é processada no MySQL como um ALTER TABLE, e estas restrições
também se aplicam a ele.

Ao fazer a verificação de chaves estrangeiras, o InnoDB define o bloqueio a nivel de linhas


compartilhadas em registros filhos e pais que ele precisa verificar. O InnoDB verifica a
restrição de chaves estrangeiras imediatamente: a verificação não é aplicada no commit da
transaçao.

Se você quiser ignorar as restrições de chaves estrangeiras durante, por exemplo um operação
LOAD DATA, você pode fazer SET FOREIGN_KEY_CHECKS=0.

O InnoDB lhe permite apagar qualquer tabela mesmo que ela quebre a restrição de chaves
estrangeira que referencia a tabela. Ao apagar um tabela restrição que é definida na instrução
create também é apagada.

Se você recriar uma tabela que foi apagada, ela deve ter uma definição de acordo com a
restrição de chaves estrangeiras que faz referência a ela. Ela deve ter os nomes e tipos de
colunas corretor e deve ter os índices na chave referenciada como indicado acima. Se esta
condição não for satisfeita, o MySQL retornará o erro de número 1005 e se refere ao errno 150
na string de mensagem de erro.

A partir da versão 3.23.50 o InnoDB retorna da definição de chave estrangeira de uma tabela
quando você chama

SHOW CREATE TABLE seunometabela

Assim o MYSQLDUMP também produz as difinições de tabelas corretas no arquivo dump e não
se esquece das chaves estrangeiras.

Você também pode listar as restrições de chaves estrangeiras de uma tabela T com

SHOW TABLE STATUS FROM seubancodedados LIKE 'T'

As restrições de chaves estrangeiras são listadas no comentário da tabela impresso na saída.

This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The
original Reference Manual is in English, and this translation is not necessarily as up to date as the
English version.
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 28 de 71

 CRIANDO AS TRÊS TABELAS PRIMÁRIAS (C1)

Tabela Materias – Primária – C1


CodMat Nr Inteiro, Não Nulo, Chave Primária,
NomeMat Texto (30),
ChMat Nro Inteiro Curto(Small),

Tabela Professores – Primária – C1


CodProf Nr Inteiro, Não Nulo, Chave Primária,
NomeProf Texto (30)
TelProf Texto (15)

Tabela Alunos – Primária – C1


MatricAlu Nr Inteiro, Não Nulo, Chave Primária,
NomeAlu Texto (30)

CREATE TABLE Materias(


CodMat INT UNSIGNED NOT NULL,
NomeMat VARCHAR(30),
ChMat SMALLINT) UNSIGNED,
CONSTRAINT PkMat PRIMARY KEY (CodMat) );

mysql> use mapas


Database changed

mysql> create table Materias (


-> CodMat int unsigned not null,
-> NomeMat varchar(30),
-> ChMat smallint unsigned,
-> constraint PkMat primary key (CodMat));

Query OK, 0 rows affected (0.08 sec)

mysql> desc Materias;


+---------+---------------------+-------+------+----------+--------+
| Field | Type | Null | Key | Default | Extra |
+---------+---------------------+-------+------+----------+--------+
| CodMat |int(10) unsigned | NO | PRI | NULL | |
| NomeMat |varchar(30) | YES | | NULL | |
| ChMat |smallint(5) unsigned | YES | | NULL | |
+---------+---------------------+-------+------+----------+--------+
3 rows in set (0.03 sec)

mysql>
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 29 de 71

mysql> create table Professores (


-> CodProf int unsigned not null,
-> NomeProf varchar(30),
-> TelProf varchar(15),
-> constraint PkProf primary key (CodProf) ) ;
Query OK, 0 rows affected (0.08 sec)

mysql> desc Professores;


+----------+--------------------+-------+--------+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------+--------------------+-------+--------+---------+-------+
| CodProf | int(10) unsigned | NO | PRI | NULL | |
| NomeProf | varchar(30) | YES | | NULL | |
| TelProf | varchar(15) | YES | | NULL | |
+----------+--------------------+-------+--------+---------+-------+
3 rows in set (0.02 sec)

mysql> show tables;


+----------------------+
| Tables_in_mapas |
+----------------------+
| materias |
| professores |
+----------------------+
2 rows in set (0.11 sec)

mysql> create table Alunos (


-> MatricAlu int unsigned not null,
-> NomeAlu varchar(30) not null,
-> Constraint PkAlu primary key (MatricAlu) ) ;
Query OK, 0 rows affected (0.11 sec)

mysql> show tables;


+--------------------------+
| Tables_in_mapas |
+--------------------------+
| alunos |
| materias |
| professores |
+--------------------------+
3 rows in set (0.00 sec)

mysql>
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 30 de 71

 CRIANDO AS TABELAS SECUNDÁRIAS (C2, C3 E C4)

Tabela MCA – Secundária – C2


CodMCA Nr Inteiro, Não Nulo, Chave Primária,
DataMCA data, Formato yyyy-mm-dd,
CodMat Nr Inteiro, Não Nulo, Chave Estrangeira (Foreign Key),
CodProf Nr Inteiro, Não Nulo, Chave Estrangeira (Foreign Key),

Tabela AlunosDeMCA – Secundária – C3


CodMCA Nr Inteiro, Não Nulo, Chave Primária,
MatricAlu Nr Inteiro, Não Nulo, Chave Primária,
NotaAlu Nr Decimal(4,2)

Tabela DiasLetivosDeAlunosDeMCA – Secundária – C4


Abreviando para DiasLetivos
CodMCA Nr Inteiro, Não Nulo, Chave Primária,
MatricAlu Nr Inteiro, Não Nulo, Chave Primária,
DT Data, Não Nulo, Chave Primária,
Fi bool (verdadeiro ou falso)

CREATE TABLE MCA (


CodMCA INT UNSIGNED NOT NULL,
DataMCA DATE,
CodMat INT UNSIGNED NOT NULL,
CodProf INT UNSIGNED NOT NULL,
CONSTRAINT PkMCA PRIMARY KEY (CodMCA),
CONSTRAINT FkMat FOREIGN KEY (CodMat) REFERENCES Materias (CodMat),
CONSTRAINT FkProf FOREIGN KEY (CodProf) REFERENCES Professores (CodProf) );

mysql> create table MCA (


-> CodMCA int unsigned not null,
-> DataMCA date,
-> CodMat int unsigned not null,
-> CodProf int unsigned not null,
-> constraint PkMCA Primary Key (CodMCA),
-> constraint FkMat Foreign Key (CodMat) References Materias (CodMat),
-> constraint PkProf Foreign Key (CodProf) References Professores (CodProf) ) ;

Query OK, 0 rows affected (0.03 sec)


DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 31 de 71

mysql> show tables;


+-----------------+
| Tables_in_mapas |
+-----------------+
| alunos |
| materias |
| mca |
| professores |
+-----------------+
4 rows in set (0.02 sec)

mysql> desc mca;


+---------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------+---------------------+------+-----+---------+-------+
| CodMCA | int(10) unsigned | NO | PRI | NULL | |
| DataMCA | date | YES | | NULL | |
| CodMat | int(10) unsigned | NO | MUL | NULL | |
| CodProf | int(10) unsigned | NO | MUL | NULL | |
+---------+---------------------+------+-----+---------+-------+
4 rows in set (0.03 sec)

mysql> Create Table AlunosMCA (


-> CodMCA int unsigned not null,
-> MatricAlu int unsigned not null,
-> NotaAlu decimal(4,2),
-> Constraint PkAlunosMCA Primary Key (CodMCA, MatricAlu),
-> Constraint FkAlunosMCA Foreign Key (MatricAlu) References Alunos (MatricAlu));
Query OK, 0 rows affected (0.08 sec)

mysql> desc AlunosMCA;


+-----------+-------------------+------+------+---------+----------+
| Field | Type | Null | Key | Default | Extra |
+-----------+-------------------+------+------+---------+----------+
| CodMCA | int(10) unsigned | NO | PRI | NULL | |
| MatricAlu | int(10) unsigned | NO | PRI | NULL | |
| NotaALu | decimal(4,2) | YES | | NULL | |
+-----------+-------------------+------+------+---------+----------+
3 rows in set (0.00 sec)

mysql> Create table DiasLetivos (  simplificando para DiasLet )


-> CodMCA int unsigned not null,
-> MatricAlu int unsigned not null,
-> DT date not null,
-> Fi bool,
-> constraint PkDiasLetivos Primary Key (CodMCA, MatricAlu, DT),
-> constraint FkDiasLetivos Foreign Key (CodMCA, MatricAlu) References
AlunosDeMCA (CodMCA, MatricAlu));
Query OK, 0 rows affected (0.06 sec)
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 32 de 71

 CRIANDO E VERIFICANDO A TABELA DIASLETIVOS


mysql> Create Table DiasLet (
-> CodMCA int unsigned not null,
-> MatricAlu int unsigned not null,
-> Dt date not null,
-> Fi bool,
-> Constraint PkDiasLet Primary Key (CodMCA, MatricAlu, Dt),
-> Constraint FkDiasLet Foreign Key (CodMCA, MatricAlu) References AlunosMCA
(CodMCA, MatricAlu));
Query OK, 0 rows affected (0.03 sec)

mysql> desc DiasLet;


+----------+--------------------+------+--------+----------+---------+
| Field | Type | Null | Key | Default | Extra |
+----------+--------------------+------+--------+----------+---------+
| CodMCA | int(10) unsigned | NO | PRI | NULL | |
| MatricAlu| int(10) unsigned | NO | PRI | NULL | |
| DT | date | NO | PRI | NULL | |
| Fi | tinyint(1) | YES | | NULL | |
+----------+--------------------+------+--------+----------+---------+
4 rows in set (0.02 sec)

 ALTERANDO A TABELA ALUNOS PARA CONTER A COLUNA SEXOALUNO


mysql> Alter Table Alunos
-> add SexoAlu enum('M', 'F');  enum significa que só aceita M ou F na coluna SexoAlu
Query OK, 0 rows affected (0.08 sec)
Records: 0 Duplicates: 0 Warnings: 0

mysql> desc Alunos;


+-----------+---------------------+-------+------+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------+---------------------+-------+------+---------+-------+
| MatricAlu | int(10) unsigned | NO | PRI | NULL | |
| NomeAlu | varchar(30) | NO | | NULL | |
| SexoAlu | enum('M','F') | YES | | NULL | |
+-----------+---------------------+-------+------+---------+-------+
3 rows in set (0.02 sec)

 ALTERANDO A TABELA ALUNOS PARA MODIFICAR A COLUNA SEXOALUNO


PARA NÃO PERMITIR VALORES NULOS
mysql> Alter Table Alunos
-> modify SexoAlu enum('M','F') not null;
Query OK, 0 rows affected (0.07 sec)
Records: 0 Duplicates: 0 Warnings: 0

mysql> desc alunos;


+--------------+-------------------------+-------+--------+------------+----------+
| Field | Type | Null | Key | Default | Extra |
+--------------+-------------------------+-------+--------+------------+----------+
| MatricAlu | int(10) unsigned | NO | PRI | NULL | |
| NomeAlu | varchar(30) | NO | | NULL | |
| SexoAlu | enum('M','F') | NO | | NULL | |
+--------------+------------------------+--------+--------+------------+----------+
3 rows in set (0.01 sec)
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 33 de 71

 INSERINDO VALORES NAS COLUNAS DE ALUNOS


Na inserção deverão ser observados três elementos:
- O nome da tabela que receberá inserção de dados;
- Os nomes das colunas que serão populadas dentro da tabela; e
- Os valores que serão adicionados para popular as colunas

mysql> Insert into Alunos


-> (MatricAlu, NomeAlu, SexoAlu)
-> Values ('123456', 'Abelardo Barbosa', 'M');
Query OK, 1 row affected (0.01 sec)

mysql> Insert into Alunos


-> Values ('123457', 'Bastiana Brejão', 'F');
Query OK, 1 row affected (0.00 sec)

mysql> select * from Alunos;


+-----------------+-----------------------------+-------------+
| MatricAlu | NomeAlu | SexoAlu |
+-----------------+-----------------------------+-------------+
| 123456 | Abelardo Barbosa | M |
| 123457 | Bastiana Brejão |F |
+-----------------+-----------------------------+--------------+
2 rows in set (0.00 sec)

 RETOMANDO A SESSÃO:
Setting environment for using XAMPP for Windows.

Agnello@PAVILION C:\Xampp
# cd mysql\bin

Agnello@PAVILION C:\Xampp\mysql\bin
# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.1.37 Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> use mapas


Database changed

mysql> show tables ;


+-------------------------+
| Tables_in_mapas |
+-------------------------+
| alunos |
| alunosmca |
| diaslet |
| materias |
| mca |
| professores |
+--------------------------+
6 rows in set (0.13 sec)
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 34 de 71

 INSERINDO MAIS VALORES NAS COLUNAS DE ALUNOS


Na inserção observar: como vamos alimentar todas as três colunas (matrícula, nome e sexo)
podemos dispensar a linha de nomes das colunas e irmos direto para as linhas Values.
 OS ALUNOS A SEREM INCLUÍDOS SÃO:

Matrícula Nome Sexo


123458 Aluno Oito M
123459 Aluna novembro F
123460 Aluno Sessenta M
123461 Aluna Sessenta e Hum F

 EXIBIR O RESULTADO ATÉ AQUI

mysql> Select * from Alunos;


+--------------+--------------------------------+------------+
| MatricAlu | NomeAlu | SexoAlu |
+--------------+--------------------------------+------------+
| 123456 | Abelardo Barbosa | M |
| 123457 | Bastiana Brejão | F |
| 123458 | Aluno Oito | M |
| 123459 | Aluna Nove | F |
| 123460 | Aluno Sessenta | M |
| 123461 | Aluna Sessenta e Hum | F |
+--------------+--------------------------------+------------+
6 rows in set (0.00 sec)

 INCLUIR MAIS OS ALUNOS A SEGUIR:

Matrícula Nome Sexo


123471 Aluno Setenta e Hum M
123472 Aluna Setenta e Dois F
123474 Aluno Setenta e Quatro M
123473 Aluna Setenta e Três F
1 Aluno Número Um M

 RELACIONAR OS ALUNOSEM ORDEM ALFABÉTICA:

mysql> Insert into Alunos


-> Values ('123471', 'Aluno Setenta e Hum', 'M'),
-> Values ('123472', 'Aluna Setenta e Dois', 'F'), NÃO PODE REPETIR VALUES
-> Values ('123474', 'Aluno Setenta e Quatro', 'M');
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use near 'Value
s ('123472', 'Aluna Setenta e Dois', 'F'),
Values ('123474', 'Aluno Setenta' at line 3
mysql> INSERT INTO ALUNOS
-> Values ('123471', 'Aluno Setenta e Hum', 'M'),
-> ('123472', 'Aluna Setenta e Dois', 'F'),
-> ('123474', 'Aluno Setenta e Quatro', 'M');

Query OK, 3 rows affected (0.00 sec)


Records: 3 Duplicates: 0 Warnings: 0
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 35 de 71

mysql> SELECT * FROM ALUNOS;


+------------+------------------------+------------+
| MatricAlu | NomeAlu | SexoAlu |
+------------+------------------------+------------+
| 123456 | Abelardo Barbosa | M |
| 123457 | Bastiana Brejão | F |
| 123458 | Aluno Oito | M |
| 123459 | Aluna Nove | F |
| 123460 | Aluno Sessenta | M |
| 123461 | Aluna Sessenta e Hum | F |
| 123471 | Aluno Setenta e Hum | M |
| 123472 | Aluna Setenta e Dois | F |
| 123474 | Aluno Setenta e Quatro | M |
+------------+------------------------+------------+
9 rows in set (0.00 sec)

mysql> INSERT INTO ALUNOS


-> Values ('123473', 'Aluna Setenta e Três', 'F');
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM ALUNOS;


+------------+------------------------+---------+
| MatricAlu | NomeAlu | SexoAlu |
+------------+------------------------+---------+
| 123456 | Abelardo Barbosa | M |
| 123457 | Bastiana Brejão | F |
| 123458 | Aluno Oito | M |
| 123459 | Aluna Nove | F |
| 123460 | Aluno Sessenta | M |
| 123461 | Aluna Sessenta e Hum | F |
| 123471 | Aluno Setenta e Hum | M |
| 123472 | Aluna Setenta e Dois | F |
| 123474 | Aluno Setenta e Quatro | M |
| 123473 | Aluna Setenta e Três | F |
+------------+------------------------+---------+
10 rows in set (0.00 sec)

mysql> INSERT INTO ALUNOS


-> Values ('1', 'Aluno Número Um', 'M');
Query OK, 1 row affected (0.00 sec)

mysql> Select * from Alunos order by NomeAlu;


+-------------+--------------------------+---------+
| MatricAlu | NomeAlu | SexoAlu |
+-------------+--------------------------+---------+
| 123456 | Abelardo Barbosa | M |
| 123459 | Aluna Nove | F |
| 123461 | Aluna Sessenta e Hum | F |
| 123472 | Aluna Setenta e Dois | F |
| 123473 | Aluna Setenta e Três | F |
| 1 | Aluno Número Um | M |
| 123458 | Aluno Oito | M |
| 123460 | Aluno Sessenta | M |
| 123471 | Aluno Setenta e Hum | M |
| 123474 | Aluno Setenta e Quatro | M |
| 123457 | Bastiana Brejão | F |
+-------------+--------------------------+---------+
11 rows in set (0.02 sec)
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 36 de 71

 COMO O MYSQL TRABALHA COM ÍNDICES

Os índices são utilizados para encontrar registros com um valor específico de uma coluna
rapidamente. Sem um índice o MySQL tem de iniciar com o primeiro registro e depois ler
sequencialmente toda a tabela até que encontre os registros relevantes. Quanto maior a
tabela, maior será o custo. Se a tabela possuir um índice para as colunas em questão, o
MySQL poderá rapidamente obter uma posição para procurar no meio do arquivo de dados
sem ter que varrer todos os registros. Se uma tabela possui 1000 registros, isto é pelo menos
100 vezes mais rápido do que ler todos os registros sequencialmente. Note que se você
precisar acessar quase todos os 1000 registros, seria mais rápido acessá-los sequencialmente
porque evitaria múltiplos acessos ao disco.
Todos os índices do MySQL são armazenados e processados dentro da característica
denominada “árvore B” ou “árvore binária”. Strings são automaticamente compactadas nos
espaços finais e prefixados.

Os índices são utilizados nas seguintes situações:


- Para encontrar rapidamente os registros que coincidam com uma cláusula WHERE;
- Para recuperar registros de outras tabelas ao realizar joins;
- Para encontrar o valor MAX() ou MIN() para uma coluna indexada específica. Isto é
otimizado por um preprocessador que confere se você está utilizando WHERE;
- Durante a execução de uma ordenação ou agrupamento de uma tabela; etc.

 CRIANDO UM ÍNDICE PARA A TABELA ALUNOS

Setting environment for using XAMPP for Windows.

145270@SPASCHOAL_SFL C:\xampp
# cd mysql\bin

145270@SPASCHOAL_SFL C:\xampp\mysql\bin
# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 7
Server version: 5.1.37 Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> use mapas


Database changed

mysql> create index IdxNomeAlu on Alunos (NomeAlu(10));


Query OK, 11 rows affected (0.13 sec)
Records: 11 Duplicates: 0 Warnings: 0

mysql> desc alunos;


+-----------------+-----------------------------+----------------+----------+--------------+-----------+
| Field | Type | Null | Key | Default | Extra | |
+-----------------+-----------------------------+----------------+----------+---------------+----------+
| MatricAlu | int(10) unsigned | NO | PRI | NULL | |
| NomeAlu | varchar(30) | NO | MUL | NULL | |
| SexoAlu | enum('M','F') | NO | | NULL | |
+-----------------+-----------------------------+----------------+----------+---------------+----------+
3 rows in set (0.02 sec)
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 37 de 71

mysql> select * from Alunos


-> Order by NomeAlu;
+-------------+-------------------------------------------+------------+
| MatricAlu | NomeAlu | SexoAlu |
+-------------+-------------------------------------------+------------+
| 123456 | ABELARDO BARBOSA |M |
| 123459 | ALUNA NOVE |F |
| 123461 | ALUNA SESSENTA E HUM |F |
| 123472 | ALUNA SETENTA E DOIS |F |
| 123473 | ALUNA SETENTA E TR^S |F |
| 1 | ALUNO NLBMERO UM |M |
| 123458 | ALUNO OITO DA SILVA |M |
| 123460 | ALUNO SESSENTA |M |
| 123471 | ALUNO SETENTA E HUM |M |
| 123474 | ALUNO SETENTA E QUATRO | M |
| 123457 | BASTIANA BREJ?O |F |
+-------------+--------------------------------------------+-----------+
11 ROWS IN SET (0.02 SEC)

MYSQL> DROP INDEX IDXNOMEALU ON ALUNOS;


QUERY OK, 11 ROWS AFFECTED (0.08 SEC)
RECORDS: 11 DUPLICATES: 0 WARNINGS: 0

MYSQL> SELECT * FROM ALUNOS


-> ORDER BY NOMEALU;
+-----------------+-------------------------------------------+---------------+
| MATRICALU | NOMEALU | SEXOALU |
+-----------------+-------------------------------------------+---------------+
| 123456 | ABELARDO BARBOSA | M |
| 123459 | ALUNA NOVE | F |
| 123461 | ALUNA SESSENTA E HUM | F |
| 123472 | ALUNA SETENTA E DOIS | F |
| 123473 | ALUNA SETENTA E TR^S | F |
| 1 | ALUNO NLBMERO UM | M |
| 123458 | ALUNO OITO DA SILVA | M |
| 123460 | ALUNO SESSENTA | M |
| 123471 | ALUNO SETENTA E HUM | M |
| 123474 | ALUNO SETENTA E QUATRO | M |
| 123457 | BASTIANA BREJ?O | F |
+-----------------+-------------------------------------------+---------------+
11 ROWS IN SET (0.01 SEC)

MYSQL> CREATE INDEX IDXNOMEALU ON ALUNOS (NOMEALU(10) DESC);


QUERY OK, 11 ROWS AFFECTED (0.05 SEC)
RECORDS: 11 DUPLICATES: 0 WARNINGS: 0

MYSQL> SELECT * FROM ALUNOS


-> ORDER BY NOMEALU DESC;
+-------------------+-------------------------------------------------+---------------+
| MATRICALU | NOMEALU | SEXOALU |
+-------------------+-------------------------------------------------+---------------+
| 123457 | BASTIANA BREJAO | F |
| 123474 | ALUNO SETENTA E QUATRO | M |
| 123471 | ALUNO SETENTA E HUM | M |
| 123460 | ALUNO SESSENTA | M |
| 123458 | ALUNO OITO DA SILVA | M |
| 1 | ALUNO NLBMERO UM | M |
| 123473 | ALUNA SETENTA E TR^S | F |
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 38 de 71

| 123472 | ALUNA SETENTA E DOIS | F |


| 123461 | ALUNA SESSENTA E HUM | F |
| 123459 | ALUNA NOVE | F |
| 123456 | ABELARDO BARBOSA | M |
+-----------------+----------------------------------------------------+-----------+
11 ROWS IN SET (0.00 SEC)

MYSQL> DROP INDEX IDXNOMEALU ON ALUNOS;


QUERY OK, 11 ROWS AFFECTED (0.08 SEC)
RECORDS: 11 DUPLICATES: 0 WARNINGS: 0

MYSQL> SELECT * FROM ALUNOS


-> ORDER BY NOMEALU DESC;
+-----------------+---------------------------------------------------+---------------+
| MATRICALU | NOMEALU | SEXOALU |
+-----------------+---------------------------------------------------+---------------+
| 123457 | BASTIANA BREJAO | F |
| 123474 | ALUNO SETENTA E QUATRO | M |
| 123471 | ALUNO SETENTA E HUM | M |
| 123460 | ALUNO SESSENTA | M |
| 123458 | ALUNO OITO DA SILVA | M |
| 1 | ALUNO NLBMERO UM | M |
| 123473 | ALUNA SETENTA E TR^S | F |
| 123472 | ALUNA SETENTA E DOIS | F |
| 123461 | ALUNA SESSENTA E HUM | F |
| 123459 | ALUNA NOVE | F |
| 123456 | ABELARDO BARBOSA | M |
+-----------------+----------------------------------------------------+---------------+
11 ROWS IN SET (0.02 SEC)

 EXERCÍCIO: INCLUIR OS DADOS ABAIXO NA TABELA MATÉRIAS:

CodMat NomeMat ChMat


1 Modelagem e Análise Funcional 40
2 Análise e Modelagem de Dados 40
3 Análise e Modelagem de Process 40
4 Técnicas de Programação I 40
5 Técnicas de Programação II 80
6 Adm e Proj de Bco de Dados 40
7 Linguagem C - I 40
8 Linguagem C - II 40
9 Linguagem Java I 80
10 Linguagem Java II 80
11 Linguagem VB I 40
12 Linguagem VB II 40
13 Linguagem Delphi I 40
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 39 de 71

CodMat NomeMat ChMat


14 Linguagem Delphi II 40
15 Arquitetura de SW I 80
101 Elicitação de Requisitos 40
102 Codificação Assembler 80
103 Depuração de Código 120
104 Estatística Aplicada 40
105 Física Quântica 120
106 Gestão de Projetos 72
107 História da Cibernética 40
108 Indução Estática 12
109 Java Script 40
110 Lógica Aplicada 72
111 Monitoração de Ambientes 120

 APÓS A INCLUISÃO TEREMOS:

mysql> select * from materias;

+--------+---------------------------------+-----------+
| CodMat | NomeMat | ChMat |
+--------+---------------------------------+-----------+
| 1 | Modelagem e Analise Funcional | 40 |
| 2 | Analise e Modelagem de Dados | 40 |
| 3 | Analise e Modelagem de Process | 40 |
| 4 | Tecnicas de Programacao I | 40 |
| 5 | Tecnicas de Programacao II | 80 |
| 6 | Adm e Proj de Bco de Dados | 40 |
| 7 | Linguagem C - I | 40 |
| 8 | Linguagem C - II | 40 |
| 9 | Linguagem Java I | 80 |
| 10 | Linguagem Java II | 80 |
| 11 | Linguagem VB I | 40 |
| 12 | Linguagem VB II | 40 |
| 13 | Linguagem Delphi I | 40 |
| 14 | Linguagem Delphi II | 40 |
| 15 | Arquitetura de SW I | 80 |
| 101 | Elicitacao de Requisitos | 40 |
| 102 | Codificacao Assembler | 80 |
| 103 | Depuracao de Codigo | 120 |
| 104 | Estatistica Aplicada | 40 |
| 105 | Fisica Quantica | 120 |
| 106 | GestÒo de Projetos | 72 |
| 107 | Historia da Cibernetica | 40 |
| 108 | Inducao Estatica | 12 |
| 109 | Java Script | 40 |
| 110 | Logica Aplicada | 72 |
| 111 | monitoraþÒo de Ambientes | 120 |
+--------+---------------------------------+-----------+
26 rows in set (0.00 sec
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 40 de 71

 EXERCÍCIO: INCLUIR OS DADOS ABAIXO NA TABELA PROFESSORES:

CodProf NomeProf TelProf


1 Antonio Pereira (11) 8765-0880 |
2 Antonio Ramos (11) 8766-0880 |
3 Carla Ramos (11) 9766-2280 |
4 Denise Goncalves (11) 8136-1234 |
5 Vitoria Ramos (11) 6766-0812 |
6 Sergio Agnello (11) 9115-8616 |
7 Joao da Silva Rusda (11) 9264-0190 |
8 Joao Carlos Pereira (11) 2366-0880 |
9 Maiara Alencar (11) 9966-0890 |
10 Marcia Bretao Silva (11) 9343-8523 |

 APÓS A INCLUISÃO TEREMOS:

mysql> select * from professores;

+---------+---------------------+----------------+
| CodProf | NomeProf | TelProf |
+---------+---------------------+----------------+
| 1 | Antonio Pereira | (11) 8765-0880 |
| 2 | Antonio Ramos | (11) 8766-0880 |
| 3 | Carla Ramos | (11) 9766-2280 |
| 4 | Denise Goncalves | (11) 8136-1234 |
| 5 | Vitoria Ramos | (11) 6766-0812 |
| 6 | Sergio Agnello | (11) 9115-8616 |
| 7 | Joao da Silva Rusda | (11) 9264-0190 |
| 8 | Joao Carlos Pereira | (11) 2366-0880 |
| 9 | Maiara Alencar | (11) 9966-0890 |
| 10 | Marcia Bretao Silva | (11) 9343-8523 |
+---------+---------------------+----------------+
10 rows in set (0.00 sec)

mysql>
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 41 de 71

 ATUALIZAÇÃO DE DADOS – COMANDO UPDATE

UPDATE nome_tabela SET nome_coluna1=expr1 [, nome_coluna2=expr2 ...] [WHERE


definição_where]

UPDATE é aplicado a uma tabela e a cláusula SET atribui a um campo o valor de uma
expressão que pode ou não conter o valor de um campo da própria tabela. A cláusula WHERE
restringe as atualizações apenas aos registro que satisfação suas condições.

A partir da MySQL Versão 4.0.4, você também pode realizar operações UPDATE que cobrem
múltiplas tabelas.

Exemplo:
UPDATE Alunos
Set NomeAlu = ‘Aluno Oito da Silva’,
Where MatricAlu = ‘123458’;

mysql> UPDATE ALUNOS


-> set NomeAlu = 'Aluno Oito da Silva'
-> Where MatricAlu = 123458;
Query OK, 1 row affected (0.07 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> SELECT * FROM ALUNOS;


+------------+------------------------+----------+
| MatricAlu | NomeAlu | SexoAlu |
+------------+------------------------+----------+
| 123456 | Abelardo Barbosa | M |
| 123457 | Bastiana Brejão | F |
| 123458 | Aluno Oito da Silva | M |
| 123459 | Aluna Nove | F |
| 123460 | Aluno Sessenta | M |
| 123461 | Aluna Sessenta e Hum | F |
| 123471 | Aluno Setenta e Hum | M |
| 123472 | Aluna Setenta e Dois | F |
| 123474 | Aluno Setenta e Quatro | M |
| 123473 | Aluna Setenta e Três | F |
| 1 | Aluno Número Um | M |
+------------+------------------------+----------+
11 rows in set (0.00 sec)

 ATUALIZAÇÃO DE DADOS – COMANDO DELETE:

O comando DELETE é usado para apagar registros de uma tabela em um banco de dados.

DELETE FROM nome_tabela WHERE nome_coluna = valor_coluna

Nota: Observe a cláusula WHERE na sintaxe do DELETE. A cláusula WHERE especifica que
registro ou registros devem ser apagados. Se você omitir a cláusula WHERE, todos os registros
serão excluídos!

Exemplo:

Delete From Alunos Where MatricAlu = 1;


DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 42 de 71

 VERIFICANDO A INTEGRIDADE REFERENCIAL NA TABELA MCA:

SELECT `mca` . *
FROM `mca`
LEFT JOIN `materias` ON `mca`.`CodMat` = `materias`.`CodMat`
WHERE `materias`.`CodMat` IS NULL
AND `mca`.`CodMat` IS NOT NULL
LIMIT 0 , 30

Setting environment for using XAMPP for Windows.

145270@SPASCHOAL_SFL C:\xampp
# CD MYSQL\BIN

145270@SPASCHOAL_SFL C:\xampp\mysql\bin
# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 39
Server version: 5.1.37 Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> use mapas


Database changed

mysql> select mca.*


-> from mca
-> left join materias on mca.codmat = materias.codmat
-> where materias.codmat is null
-> and mca.codmat is not null;
Empty set (0.00 sec)

mysql> insert into mca


-> Values(2010005, '2010-02-16', '190', '1000');
Query OK, 1 row affected (0.00 sec)

mysql> select mca.* from mca;


+-----------+------------+---------+---------+
| CodMCA | DataMCA | CodMat | CodProf |
+-----------+-----------------+----+---------+
| 2010001 | 2010-03-01 | 1 | 3 |
| 2010002 | 2010-03-15 | 6 | 3 |
| 2010003 | 2010-03-16 | 2 | 5 |
| 2010005 | 2010-02-16 | 190 | 1000 |
+-----------+------------+---------+---------+
4 rows in set (0.00 sec)
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 43 de 71

 QUANDO A VERIFICAÇÃO DA INTEGRIDADE REFERENCIAL FALHA:

Ao analisarmos o result table da última consulta, vamos perceber que o servidor MySql não
verificou se a integridade referencial da tabela MCA com Matérias e com Professores estava ou
não sendo agredida.
Se realizamos o projeto corretamente, procedendo a normalização como manda o figurino e o
Ted Codd ; - )) como foi que a coisa desandou desta forma?

A parte do texto a seguir foi produzida por Eber M. Duarte e publicada na internet
nas URL indicadas, assim como publicado na revista SQL Magazine. Procedi apenas
pequenas adaptações, sem ferir o conteúdo, visando nosso maior entendimento no contexto
do nosso estudo.
Texto extraído da internet nos endereços:
http://www.criarweb.com/artigos/674.php
http://forum.imasters.uol.com.br/index.php?/topic/100466-integridade-referencial-no-mysql/.

TRABALHANDO COM OS VÁRIOS TIPOS DE TABELAS DO MYSQL


IMPLEMENTANDO INTEGRIDADE REFERENCIAL NO MYSQL

Matéria escrita por Eber M. Duarte

O MySQL possui uma característica um pouco diferente dos outros sistemas gerenciadores de
banco de dados, uma vez que no MySQL é possível escolher o tipo da tabela no momento da
criação da mesma. O formato de armazenamento dos dados, bem como alguns recursos do
banco de dados são dependentes do tipo de tabela escolhido. Vamos ver os tipos de tabelas
suportados pelo MySQL e as suas características.

A definição do tipo de tabela se dá por meio do comando CREATE TABLE, como mostrado a
seguir:

CREATE TABLE teste (


id INT NOT NULL,
texto CHAR(30) NOT NULL,
PRIMARY KEY (id)
) TYPE=MyISAM;

No comando acima, TYPE=MyISAM, indica que a tabela criada será do tipo MyISAM, que é o
valor default caso não seja informado o TYPE. A partir da versão 4.0.18 você pode utilizar
ENGINE como sinônimo de TYPE. A seguir estão apresentados os tipos de tabelas existentes
no MySQL:

1. MyISAM:

Este é o tipo de tabela padrão do MySQL. Caso não seja informado o tipo de tabela, o MySQL
criará a tabela do tipo MyISAM. O tipo de tabela default pode ser alterado incluindo-se no
arquivo de configuração, a opção descrita a seguir: default-table-type=tipo.

As tabelas MyISAM são armazenadas em 3 arquivos: .FRM que armazena a definição da


tabela, o arquivo .MYD que contém os dados e o .MYI contendo os índices. Estas tabelas são
de grande desempenho para leitura, uma vez que os seus índices são armazenados em
árvores binárias balanceadas, o que provê um ganho para o acesso às informações. O
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 44 de 71

MyISAM não provê controle de transações (commit ou rollback) e também não possue
integridade referencial, isto é, ao incluir uma chave estrangeira com alguns constraints, esta
servirá apenas como documentação, mas as restrições não serão respeitadas pelo banco.
Como as tabelas MyISAM são representadas por arquivos no modelo uma tabela para três
arquivos, existe, em alguns sistemas operacionais, restrições quanto ao tamanho destas
tabelas. No Linux, por exemplo, existe a restrição de 2G/4GB por arquivo, com isto uma tabela
MyISAM poderia ter somente 2G/4GB de dados. Para superar esta limitação foi introduzido na
versão 4.1 a opção RAID_TYPE utilizada no CREATE TABLE, que permite ao próprio MySQL
dividir o armazenamento da tabela em vários arquivos. Com isto, o tamanho da tabela MyISAM
não fica preso ao tamanho máximo de arquivo do sistema operacional. O principal problema
encontrado com as tabelas MyISAM é que elas possuem um mecanismo de locks por tabela.
Assim, todas as vezes que há uma escrita na tabela, o MySQL precisa travar a tabela como um
todo, o que bloqueia por um instante o acesso à esta tabela, mesmo para processos que
tentem acessar registros que estão sendo modificados. Assim, é gerada uma fila de espera até
que o lock seja liberado e os outros processos possam ser executados. Por outro lado, estas
tabelas são extremamente rápidas, devido à sua arquitetura simplificada.

2. HEAP:

Tabelas HEAP são armazenadas em memória e por isto são extramente rápidas, por outro
lado o seu conteúdo é volátil, uma vez que não são gravadas em disco. Caso haja uma queda
do SGBD os dados destas tabelas serão perdidos. Além disto, é necessário um processo para
dar a carga inicial nos dados quando o servidor de banco iniciar e sua execução. A principal
aplicação das tabelas HEAP seria para tabelas que são consultadas com muita frequência, mas
que não sofrem muitas alterações (lookup tables).

3. MERGE:

As tabelas MERGE são coleções de tabelas MyISAM idênticas. Este recurso permite a divisão
de uma tabela grande em várias partes menores, e ainda assim permite acesso ao conteúdo
de todas elas como se fossem uma única tabela. O exemplo a seguir ilustra a criação de uma
tabela MERGE:

CREATE TABLE t1 (
a INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
message CHAR(20) );
CREATE TABLE t2 (
a INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
message CHAR(20) );
INSERT INTO t1 (message) VALUES ('Testing'),('table'),('t1');
INSERT INTO t2 (message) VALUES ('Testing'),('table'),('t2');
CREATE TABLE total (
a INT NOT NULL AUTO_INCREMENT,
message CHAR(20), INDEX(a)
)TYPE=MERGE UNION=(t1,t2);
SELECT * FROM total;
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 45 de 71

a message
-----------------------
1 Testing
2 Table
3 t1
1 Testing
2 Table
3 t2

Percebam que as tabelas t1, t2 e total são idênticas e as duas primeiras são tabelas MyISAM
(foi omitido o TYPE no comando CREATE TABLE). Ao se submeter um SELECT na tabela total,
você tem acesso ao conteúdo das tabelas t1 e t2, simultaneamente. A principal vantagem da
tabela MERGE é permitir a divisão de tabelas grandes em tabelas pequenas, mais facilmente
gerenciadas. Também permite superar as limitações do sistema operacional em relação ao
tamanho de arquivos, uma vez que a tabela seria dividida em várias partes, onde cada parte
poderia atingir o tamanho máximo de arquivo. A desvantagem é que podemos fazer apenas
MERGE de tabelas MyISAM idênticas.

4. BDB:

O tipo de tabela BDB vem de BerkeleyDB, e foi desenvolvido pela Sleepycat


(http://www.sleepycat.com). O BDB provê ao MySQL um manipulador de tabelas com controle
de transação, isto é, você poderá utilizar os comandos COMMIT e ROLLBACK, além de fornecer
a recuperação automática de dados em caso de queda do sistema. O BDB apresenta um
mecanismo de lock em nível de página, onde apenas os dados de uma mesma página ficarão
bloqueados durante um perído de lock. Além disto, você poderá ter vários locks ativos numa
única tabela BDB, uma vez que a tabela poderá ser constituída de várias páginas.

5. InnoDB:

O InnoDB é um tipo de tabela transacional, desenvolvido pela InnoDBase Oy. A partir da


versão 4.0 do MySQL, ele passa a ser parte integrante das distribuições do MySQL. O InnoDB
apresenta, além da capacidade transacional, outros recursos importantes:

 Integridade referencial, com implementação dos constraints SET NULL, SET DEFAULT,
RESTRICT e CASCADE;
 Ferramenta de backup on-line (ferramenta comercial, não GPL);
 Lock de registro, como Oracle, DB2, etc;
 Níveis de isolamento;
 Armazenamentos de dados em tablespace.

Por se tratar de um tipo de tabela com recursos mais avançados, requer mais espaço em
memória e disco, além de se apresentar, em determinadas situações, um pouco mais lento
que MyISAM. Apesar disto, o InnoDB tem se mostrado extremamente rápido se comparado
com outros SGBDs transacionais.

A vantagem da utilização de tipos de tabela é que você poderá optar por utilizar um
determinado tipo ou outro dependendo dos requisitos exigidos pela sua aplicação. Por
exemplo, se a sua aplicação é apenas de consulta você pode optar pelo tipo MyISAM em vez
do InnoDB, com isto você evita o overhead da transação, obtendo um maior desempenho. É
importante lembrar que você poderá utilizar vários tipos de tabelas em um mesmo
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 46 de 71

banco de dados. Neste caso, deve-se tomar cuidado com a utilização de determinados
recursos, por exemplo, se você tiver uma transação envolvendo tabelas InnoDB e MyISAM e
você submeter um comando ROLLBACK, apenas os comandos executados no InnoDB serão
desfeitos, enquanto que os comandos executados no MyISAM persistirão. A utilização do tipo
de tabela correto é um fator chave para determinar o desempenho da sua aplicação.

Assim, vimos que no MySQL é possível escolher o formato de armazenamento da tabela no


momento da sua criação, o que dá a flexibilidade de optar por um ou outro tipo de tabela,
dependendo do tipo de aplicação a ser desenvolvida. Vimos também que determinados
recursos do SGBD estão diretamente relacionados ao tipo de tabela escolhido, tais como,
controle de transação, níveis de lock e integridade referencial.

Para trabalharmos com integridade referencial, isto é, para adicionarmos restrições de


integridade (constraints) às chaves estrangeiras, é necessário criar as tabelas como
InnoDB. Este recurso está disponível somente para este tipo de tabela, embora seja possível
definir chaves estrangeiras e restrições outros tipos de tabelas por razões de compatibilidade.
O detalhe é que neste caso, estas definições terão o efeito apenas de documentação, ou seja,
o MySQL não respeitará os constraints definidos.

O InnoDB implementa as restrições de integridade CASCADE, RESTRICT, SET NULL e SET


DEFAULT. No primeiro caso, ao se remover um registro da tabela referenciada pela chave
estrangeira os registros relacionados àquele removido serão eliminados em todas as tabelas
relacionadas. O RESTRICT não permite a remoção de registros que possuam relacionamentos
em outras tabelas. Os dois últimos atribuem os valores DEFAULT ou NULL para as chaves
estrangeiras cujos registros relacionados foram excluídos. O exemplo abaixo ilustra algumas
tabelas que utilizam regras de integridade:

CREATE TABLE Alunos (


MatricAlu INT UNSIGNED NOT NULL PRIMARY KEY,
NomeAlu VARCHAR(30) NOT NULL,
SexoAlu ENUM(‘M’, ‘F’) NOT NULL
) TYPE=InnoDB;

CREATE TABLE Cursos (


IdCurso INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
NomeCurso CHAR(30) NOT NULL
) ENGINE=InnoDB;

CREATE TABLE Notas (


IdAluno INT NOT NULL,
IdCurso INT NOT NULL,
Data DATE NOT NULL,
Nota DOUBLE NOT NULL,
PRIMARY KEY (IdAluno, IdCurso, Data),
INDEX I2 (IdCurso),
FOREIGN KEY (IdAluno) REFERENCES Alunos(MatricAlu) ON DELETE CASCADE,
FOREIGN KEY (IdCurso) REFERENCES Cursos(IdCurso) ON DELETE RESTRICT
) TYPE=InnoDB;

No exemplo existem 3 tabelas: aluno, que armazena os alunos de uma faculdade; a tabela
cursos que contém as disciplinas ministradas e a tabela notas com os pontos dos alunos em
todos os cursos freqüentados por eles. No modelo é possível que um curso possua várias
avaliações em datas distintas. Neste caso, foram criadas as tabelas como tipo InnoDB
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 47 de 71

(TYPE=InnoDB), para que as regras de integridade sejam respeitadas. As regras definidas


foram: um CASCADE para aluno, isto é, se for removido um registro da tabela de aluno, todas
as suas notas serão removidas automaticamente. No caso da tabela de cursos, não será
possível remover um curso que possua notas cadastradas para ele. Além da restrição ON
DELETE, o InnoDB permite também o ON UPDATE, que aplica as restrições no caso de
atualizações dos campos ralacionados entre as tabelas.

É importante ressaltar que o FOREIGN KEY não cria automaticamente um índice na(s)
coluna(s) referenciada(s). Assim, é necessário criar explicitamente um índice nas colunas que
serão chaves estrangeiras. No exemplo, a coluna aluno_id já é um índice, visto que esta é o
primeiro campo da chave primária da tabela. Como cursos_id não é o primeiro campo de
nenhuma chave, foi adicionado o índice i2 para esta chave estrangeira. Caso não seja criado o
índice nas chaves estrangeiras, o MySQL exibirá o erro "ERROR 1005: Can't create table
'./test/notas.frm' (errno: 150)", onde o erro significa que há uma definição incorreta das
chaves estrangeiras.
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 48 de 71

 TRABALHANDO COM OS RELACIONAMENTOS ENTRE TABELAS

Imaginemos a seguinte situação: uma tabela com dados de várias empresas e outra tabela
guardando os dados dos funcionários dessas empresas. Cada tabela, como não poderia ser
diferente, contém os dados específicos de sua classe de informação, ou seja, a tabela
Empresas armazena Nome, Endereço, CNPJ, entre outros dados das Empresas. A tabela
Funcionários armazena Nome, Endereço, Telefone, CPF e os demais dados de Funcionários.

Ao analisarmos a relação entre estas tabelas, encontraremos: Uma (1) Empresa pode ter
muitos (N) Funcionários, e um (1) Funcionário trabalha para uma única Empresa, em um
momento específico. Ou seja, a relação pode ser representada graficamente da seguinte
forma:

POSSUI
1  N

EMPRESAS FUNCIONÁRIOS

1 TRABALHA
1

O que resulta :

1 N
EMPRESAS FUNCIONÁRIOS

Agora vamos abstrair: O estabelecimento da relação se dá pela criação da chave de uma das
tabelas relacionadas na outra tabela. Na relação funcionário - um para uma – empresa é
possível colocarmos na tabela funcionário o código da empresa para qual trabalha. Já com
relação a empresa – uma para muitos funcionários, não dá para inserirmos o código de
funcionário na tabela de empresas, pois se podemos ter mais de um funcionário por empresa,
quantas colunas (uma para cada possível funcionário) necessitaríamos reservar? Não
obteríamos um número sem estabelecermos um limite para essa relação, o que na vida
prática, convenhamos, não parece ser uma prática louvável, não é mesmo?

Como estamos observando pelo funcionário, então a gente fala de um campo na tabela
funcionários. Bastaria, para resolver o problema de relações, acrescentar um campo na tabela
funcionário para dizer a que empresa ele pertence.

Mas se observarmos pela lado da empresa, temos a relação de um para muitos (uma empresa
para muitos funcionários) ou, se em algum caso enxergarmos uma relação muitos para
muitos, então precisaremos de uma tabela intermediária.

Vamos ver na prática, como funciona: Vamos imaginar utro caso onde teríamos uma tabela de
empresas e uma tabela de categorias. Uma empresa pode ter mais de uma categoria, ou seja
uma relação de um para muitos. Por outro lado, uma categoria pode estar associada a diversas
empresas. Desta forma, obteríamos a relação de muitos para muitos. A solução para este
relacionamento (N para M) é criarmos uma tabela intermediária para resolver nosso problema.
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 49 de 71

Assim, teríamos a tabela Empresas com os seguintes dados:


- CodEmpresa
- NomeEmpresa
- EndereçoEmpresa; e

A outra tabela, Categorias com os dados:


- CodCategoria
- Titulo

A tabela intermediária estabeleceria a relação muitos para muitos que necessitamos para
fechar a relação. Vamos nomeá-la EmpreCat, mas poderíamos colocar qualquer outro nome
que entendêssemos representar adequadamente esta combinação. EmpreCat contaria com os
seguintes campos:
- CodEmpresa
- CodCategoria

Ambos os campos seriam chave, para que nunca existisse duplicidade no cadastro de uma
mesma empresa para uma mesma categoria. E, além disto, cada coluna, individualmente,
seria uma chave estrangeira.

No MySql, criaríamos esta relação da seguinte forma:

CREATE TABLE EmpreCat (


CodEmpresa int(3) not null,
CodCategoria int(3) not null,
primary key(CodEmpresa, CodCategoria),
foreign key (CodEmpresa) references Empresas (CodEmpresa),
foreign key(CodCategoria) references Categorias(CodCategoria)
)Type=InnoDB;

Se desejarmos, poderemos, também, adicionar regras de eventos para cada chave


estrangeira. Um evento é um DELETE ou um UPDATE, por exemplo. Suponhamos que a
empresa com ID = 4 tenha o nome "Empresa X". Suponhamos, também, que na tabela
EmpreCat, este ID esteja associado com as categorias de IDs 2 e 3. Então, teríamos o
seguinte:

SELECT CodEmpresa, NomeEmpresa FROM Empresas WHERE CodEmpresa = 4;

+--------------+------------------+
| CodEmpresa | NomeEmpresa |
+--------------+------------------+
| 4 | Empresa X |
+--------------+------------------+

SELECT * FROM EmpreCat WHERE CodEmpresa = 4;


+---------------+--------------+
| CodEmpresa | CodCategoria |
+---------------+--------------+
| 4 | 2 |
| 4 | 3 |
+---------------+--------------+

Se comandarmos um DELETE na tabela Empresas e apagarmos a empresa CodEmpresa = 4, na


tabela EmpreCat ainda existirão aquelas referências vagas, certo? Estarão lá referenciando as
categorias 2 e 3 com uma empresa que não existe.
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 50 de 71

Para corrigir isto, deveríamos associar à chave estrangeira uma restrição (constraint) dizendo
que, no evento “ao apagar” (Delete) o registro na tabela Pai (Empresas), os registros filhos
associados na tabela filho (EmpreCat) deveriam também ser apagados. Este processo chama-
se apagar em cascata (cascade). Ou então, ao invés de apagar em cascata, poderíamos
associar ao evento ON DELETE a ação de fazer com que os registros filhos ficassem com
conteúdo nulo, ou algumas outras ações. Para fazer a ação apagar em cascata associada ao
evento ON DELETE, deveremos escrever o comando Create Table da seguinte forma:

CREATE TABLE EmpreCat (


CodEmpresa int(3) not null,
CodCategoria int(3) not null,
primary key(CodEmpresa, CodCategoria),
Foreign Key (CodEmpresa) references Empresas(CodEmpresa) ON DELETE CASCADE,
Foreign Key(CodCategoria) references Categorias(CodCategoria) ON DELETE CASCADE
);

Quando criamos um relacionamento explícito em uma tabela, utilizando chave estrangeira, isto
será útil para criarmos o que chamamos de índices. Os índices são uma forma de se percorrer
a tabela utilizando um campo específico, além daquele que é chave primária. Isto agiliza a
consulta, de forma que quando criamos chaves estrangeiras indexadas, o relacionamento entre
tabelas faz com que uma busca relacionada seja praticamente buscar em uma única tabela.

No entanto, para fazermos uma consulta relacionando tabelas, não é imprescindível existir o
relacionamento explícito. Veja o exemplo:

Uma tabela "Empresas", uma tabela "Categorias" e uma tabela "EmpreCat". Vimos como
criaríamos a tabela "EmpreCat" colocando uma chave estrangeira. Mas não dissemos como
criaríamos o índice. Portanto, vamos a ele:

CREATE TABLE Empresas (


CodEmpresa int(5) NOT NULL PRIMARY KEY,
NomeEmpresa varchar(150) NOT NULL
) TYPE=INNODB;

CREATE TABLE Categorias (


CodCategoria int(3) NOT NULL PRIMARY KEY,
NomeCategoria varchar(50) NOT NULL
) TYPE=INNODB;

CREATE TABLE EmpreCat (


CodEmpresa int(5) NOT NULL,
CodCategoria int(3) NOT NULL,
PRIMARY KEY(CodEmpresa, CodCategoria),
INDEX(CodEmpresa, CodCategoria),
FOREIGN KEY(CodEmpresa) references Empresas(CodEmpresa)
ON DELETE CASCADE,
FOREIGN KEY(CodCategoria) references Categorias(CodCategoria)
ON DELETE CASCADE
) TYPE=INNODB;

Bem, desta forma, ainda temos a conveniência de que, quando deletarmos qualquer registro na
tabela pai (Empresas, por exemplo), todos os registros da tabela filho associados àquele também
serão apagados. Mas o principal do relacionamento explícito não é isto. É que o banco de dados
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 51 de 71

SABE realmente da existência da relação entre estas tabelas. Portanto, ele sabe que as tabelas
"Empresas" e "Categorias" são as tabelas-pai da tabela "EmpreCat". Desta forma, o banco NÃO
PERMITE que venhamos inserir, na tabela filho, um registro com, por exemplo, um ID de uma
empresa que não está cadastrada na tabela "Empresas". Nem um registro com um ID de uma
categoria que não está cadastrado na tabela "Categorias". Isto que é um relacionamento definido!

Assim, o que realmente precisamos dizer é que não precisa existir chave estrangeira entre tabelas ou
um relacionamento concretamente estruturado para que consigamos fazer referências. As buscas só
não serão indexadas, mas isto nem será problema, também, pq os índices só começam a ajudar
quando a tabela começa a ficar grande (para o MySql, começar a perder performance precisamos de
uma tabela com mais de 5.000 registros, por exemplo).

Acho que agora é possível entendermos que não é questão do que é melhor entre JOIN e
relacionamento. Sempre tem que existir o JOIN. Tendo ou não relacionamento explícito entre
tabelas, na hora de consultar, precisararemos usar o JOIN.

Entenda que JOIN não é só INNER JOIN. Existem LEFT JOIN, INNER JOIN e RIGHT JOIN. E
que existem duas formas de se fazer JOIN: a que os bancos chamam de "the old JOIN style" e a que
os bancos chamam de "new JOIN style". Ou seja, antigo estilo de JOIN e novo estilo de JOIN. No
antigo, não usamos a palavra JOIN. Veja este exemplo de consulta que nos mostra todas as
categorias (não o ID, mas o nome da categoria) de determinada empresa:

SELECT
b.NomeCategoria
FROM
EmpreCat AS a,
Categorias AS b
WHERE
a.CodCategoria = b.CodCategoria AND
a.CodEmpresa = 3
ORDER BY b.NomeCategoria

Este é o velho estilo de JOIN. Colocamos nele, a cláusula WHERE, a qual é a relação entre a tabela
"a" e a tabela "b". A propósito... Este AS é, sim, o tal "alias" de tabela. "Alias" é a forma que o SQL
oferece para darmos um outro nome, (chamamos de apelido) para uma tabela. Isto simplifica
consultas pra não termos que ficar escrevendo um nome extenso da tabela ao associarmos qual
coluna desta tabela queremos referenciar. Para esta consulta de cima, se não usássemos "alias", veja
como ficaria:

SELECT
Categorias.NomeCategoria
FROM
EmpreCat,
Categorias
WHERE
EmpreCat.CodCategoria = Categorias.CodCategoria AND
EmpreCat.CodEmpresa = 3
ORDER BY Categorias.NomeCategoria;

Isto porque estamos usando somente um JOIN e buscando somente um campo. Imagine se fossem
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 52 de 71

10 campos!! Muito melhor escrever "a.campo" do que "nome_da_tabela.campo", certo?

Bem... Para o novo estilo de JOIN, a consulta acima ficaria deste jeito:

SELECT
b.categoria
FROM
EmpreCat AS a LEFT JOIN Categorias AS b ON (a.categoria_id=b.categoria_id)
WHERE a.CodEmpresa = 3
ORDER BY b.categoria;

Bem... E quanto à forma em que uma Junção ocorre? Avaliamos, até aqui, as Junções
denominadas Internas ou INNER JOIN. INNER é o default ou padrão de compra
estabelecido. Utilisamos a consulta LEFT JOIN. Existem diferenças, é claro? Mas neste
caso, as duas consultorias funcionariam, embora o mais "correto" (quando desejamos ver o
conceito dos dois, verá isto) para este caso seria o LEFT JOIN.

Assim, ficou claro que os relacionamentos para efetivarem o controle de Integridade


Referencial em cima da chave estrangeira (Foreign Key) se faz necessário trabalharmos com
tabelas do tipo InnoDB e que todos os campos referenciados sejam do mesmo tipo e
tamanho de dados, guardando inclusive particularidades do tipo sem sinal e não nulo.

Então, criamos um relacionamento com innodb que já está criando uma integridade
referencial, o resto é você acrescentar tipo assim:

ON UPDATE CASCADE ON DELETE RESTRICT

nesse exemplo ele atualiaza automaticamente uma chave estrangeira se o campo for editado
e nao deixa apagar o efeito cascade é modo cascata onde todas tabelas serao atualizadas
automaticamente

ON UPDATE NO ACTION ON DELETE NO ACTION

nesse exemplo nao será feito nada!

ON UPDATE NO ACTION ON DELETE CASCADE

nesse exemplo quando deletar um campo todos os campos relacionados serao apagados
automaticamente

e por ai vai antes de usar precisa estudar e ver uma modelagem perfeita

olha nao recomendo você usar phpmyadmin se você quer mesmo criar um banco descente
eu faço no notepad

mas no phpmyadmin se você usar chaves e banco innodb ele deixa você setar as referencias
e efeitos cascades etc...
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 53 de 71

 FUNÇÔES

O MySQL possui algumas funções que podem ser muito úteis no processamento dos dados.
Abaixo podemos ver uma tabela com algumas destas funções:

AVG(coluna)

Retorna a média dos valores da coluna.

COUNT(item)

Se item for uma coluna, será retornado a quantidade de valores não NULL nesta coluna.

Se a palavra-chave DISTINCT for colocada na frente do nome da coluna, será retornado a


quantidade de valores distintos nesta coluna.

Se for passado COUNT(*), será retornado a quantidade total de registros independente de


quantos tenham valor NULL.

MIN(coluna)

Retorna o valor mínimo da coluna.

MAX(coluna)

Retorna o valor máximo da coluna.

SDT(coluna)

Retorna o desvio padrão dos valores da coluna.

SDTDEV(coluna)

O mesmo que SDT(coluna).

SUM(coluna)

Retorna a soma dos valores da coluna.

Exemplos da utilização destas funções:

mysql> select * from pedido;


+----+---------+--------+
| nr | cliente | valor |
+----+---------+--------+
| 1 | 2 | 50.50 |
| 2 | 2 | 60.00 |
| 3 | 1 | 100.05 |
| 4 | 3 | 54.70 |
| 5 | 3 | 80.90 |
+----+---------+--------+
5 rows in set (0.00 sec)
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 54 de 71

mysql> select avg(valor) from pedido;


+------------+
| avg(valor) |
+------------+
| 69.230001 |
+------------+
1 row in set (0.00 sec)

Podemos usar a cláusula group by para calcular a média de pedidos para cada elemento de um
grupo determinado. Exemplo:

mysql> select cliente, avg(valor) from pedido group by cliente;


+---------+------------+
| cliente | avg(valor) |
+---------+------------+
| 1 | 100.050003 |
| 2 | 55.250000 |
| 3 | 67.800001 |
+---------+------------+
3 rows in set (0.04 sec)

Observe que quando usamos group by a função avg() retorna a média calculada para cada
componente do grupo especificado, no caso "cliente".

Podemos também testar o valor retornado por avg():

mysql> select cliente, avg(valor) from pedido group by cliente having


avg(valor) > 60;
+---------+------------+
| cliente | avg(valor) |
+---------+------------+
| 1 | 100.050003 |
| 3 | 67.800001 |
+---------+------------+
2 rows in set (0.02 sec)

Note que a cláusula having usada aqui tem o mesmo significado que where nas consultas
normais.

Abaixo vemos exemplos do uso de count():

mysql> select pedido.nr,cliente.nome,pedido.valor from


-> cliente left join pedido on cliente.codigo=pedido.cliente;
+------+---------+--------+
| nr | nome | valor |
+------+---------+--------+
| 3 | João | 100.05 |
| 1 | Maria | 50.50 |
| 2 | Maria | 60.00 |
| 4 | José | 54.70 |
| 5 | José | 80.90 |
| NULL | Manuel | NULL |
| NULL | Adão | NULL |
| NULL | Rodrigo | NULL |
| NULL | Davi | NULL |
| NULL | Karla | NULL |
| NULL | Samuel | NULL |
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 55 de 71

| NULL | Ana | NULL |


+------+---------+--------+
12 rows in set (0.00 sec)

mysql> select count(valor) from cliente left join pedido


-> on cliente.codigo=pedido.cliente;
+--------------+
| count(valor) |
+--------------+
| 5 |
+--------------+
1 row in set (0.00 sec)

mysql> select count(*) from cliente left join pedido on


cliente.codigo=pedido.cliente;
+----------+
| count(*) |
+----------+
| 12 |
+----------+
1 row in set (0.00 sec)

mysql>

Usando min(), max() e sum():

mysql> select * from pedido;


+----+---------+--------+
| nr | cliente | valor |
+----+---------+--------+
| 1 | 2 | 50.50 |
| 2 | 2 | 60.00 |
| 3 | 1 | 100.05 |
| 4 | 3 | 54.70 |
| 5 | 3 | 80.90 |
+----+---------+--------+
5 rows in set (0.00 sec)

mysql> select min(valor) from pedido;


+------------+
| min(valor) |
+------------+
| 50.50 |
+------------+
1 row in set (0.00 sec)

mysql> select max(valor) from pedido;


+------------+
| max(valor) |
+------------+
| 100.05 |
+------------+
1 row in set (0.00 sec)
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 56 de 71

mysql> select sum(valor) from pedido;


+------------+
| sum(valor) |
+------------+
| 346.15 |
+------------+
1 row in set (0.00 sec)

 Exercícios sobre Junções (JOINTs)


 JUNÇÔES

O que são JUNÇÕES ?


JUNÇÃO ou JOIN é o mecanismo que nos permite agrupar dados de duas ou mais tabelas em
uma única instrução SELECT.

Considere o seguinte projeto lógico de dados:

C3 C2 C1
PRATOS ESPECIAIS - PEs RESTAURANTES CHEFES

IdPE – Pk IdR – Pk IdChef - Pk


NomePE NomeR NomeChef
DescrPE EndreR NívelChef
NivelPE NivelR TelChef
ValorPE IdChef - Fk ODChef (outros dados)
DataLcto
IdRPE - Fk

C3 C1
RESTPCS PRATOS COMUNS - PCs

IdRPC (Fk) IdPC – Pk


IdPCR (Fk) Pk NomePC
DescrPC
DiferençasRPC NivelBasicoPC
ValorRPC DataLctoPC
DataLctoRPC
NivelRPC
DataLctoRPC

Criar um Banco de Dados de nome BDREST e depois criar as tabelas Restaurantes, Pratos
Especiais, Pratos Comuns e Chefes, objetivando a integridade referencial e com as
características abaixo:

C1
CHEFES (Responsáveis por Restaurantes)
IdChef Numérico INT(7) sem sinal – PK
NomeChef Texto(40) não nulo,
NívelChef Numérico INT(1) – Variando de 1 a 5 – sem sinal - não nulo – default “1”,
TelChef Numérico BIGINT(10) sem sinal,
ODChef Texto(100)

PRATOS COMUNS – PCs


IdPC Numérico INT(3) sem sinal – não nulo – PK
NomePC Texto(40) não nulo,
DescrPC Texto(100),
NívelBasicoPC Numérico INT(1) – Variando de 1 a 5 – sem sinal - não nulo – default “1”,
DataLctoPC Date
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 57 de 71

C2
RESTAURANTES
IdR Numérico INT(7) sem sinal – não nulo – PK
NomeR Texto (40) não nulo,
EnderR Texto(50),
NivelR Numérico INT(1) – Variando de 1 a 5 – sem sinal - não nulo – default “1”,
IdChef Numérico INT(7) sem sinal - FK.

C3
PRATOS ESPECIAIS – PEs
IdPE Numérico INT(3) sem sinal – não nulo – PK
NomePE Texto(40) não nulo,
DescrPE Texto(100),
NívelPE Numérico INT(1) – Variando de 1 a 5 – sem sinal - não nulo – default “1”,
ValorPE Numérico com 2 decimais, sem sinal,
IdRPE Numérico INT(7) sem sinal – FK,
DataLctoPE Date

RESTPCS
IdRPC Numérico INT(7) sem sinal – não nulo – PK e FK isoladamente
IdPCR Numérico INT(3) sem sinal - não nulo - PK e FK isoladamente
DiferençasRPC Texto (100),
ValorPPC Numérico com 2 decimais, sem sinal,
NivelRPC Numérico INT(1) – Variando de 1 a 5 – sem sinal - não nulo – default “1”,

 CRIAR O BANCO DE DADOS BDREST E DEPOIS CRIAR AS TABELAS


CONFORME APRESENTADAS NO PROJETO ACIMA:

Setting environment for using XAMPP for Windows.

145270@SPASCHOAL_SFL C:\xampp
# cd mysql\bin

145270@SPASCHOAL_SFL C:\xampp\mysql\bin
# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 132
Server version: 5.1.37 Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> create database BDRest;


Query OK, 1 row affected (0.00 sec)

mysql> use BDRest


Database changed

CRIANDO AS TABELAS C1
 Criar a tabela Chefes - C1
mysql> Create table CHEFES (
-> IdChef int(7) unsigned,
-> NomeChef char(40),
-> NivelChef enum('1', '2', '3', '4', '5') default '1',
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 58 de 71

-> TelChef BIGINT(10),


-> ODChef Varchar(100),
-> Constraint PkChef PRIMARY KEY (IdChef)
-> )type = InnoDB;
Query OK, 0 rows affected, 1 warning (0.13 sec)

 Criar a tabela Restaurantes-PratosComuns - RPCs - C1


mysql> Create table PCs (
-> IdPC Int(3) unsigned not null,
-> NomePC Char(40) not null,
-> DescrPC Varchar (100),
-> NivelBasicoPC enum('1', '2', '3', '4', '5') default '2',
-> DataLcto Date,
-> Constraint PkPC PRIMARY KEY (IdPC) ) Type=Innodb;
Query OK, 0 rows affected, 1 warning (0.09 sec)

mysql> desc PCs;


+--------+-----------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+-----------------+------+-----+---------+-------+
| IdPC | int(3) unsigned | NO | PRI | NULL | |
| NomePC | char(40) | NO | | NULL | |
+--------+-----------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

mysql>

 Criar a tabela Restaurantes - C2


CRIANDO AS TABELAS C2
mysql> Create Table Restaurantes (
-> IdR int(7) unsigned not null,
-> NomeR Char(40) not null,
-> EnderR Char(50),
-> NivelR enum('1', '2', '3', '4', '5') default '1',
-> IdChef int(7) unsigned,
-> CONSTRAINT PkR PRIMARY KEY (IdR),
-> CONSTRAINT FkR FOREIGN KEY (IdChef) REFERENCES Chefes (IdChef)
-> ON UPDATE CASCADE ON DELETE RESTRICT
-> )Type = InnoDB;
Query OK, 0 rows affected, 1 warning (0.13 sec)

mysql> Desc Restaurantes;


+--------+---------------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+---------------------------+------+-----+---------+-------+
| IdR | int(7) unsigned | NO | PRI | NULL | |
| NomeR | char(40) | NO | | NULL | |
| EnderR | char(50) | YES | | NULL | |
| NivelR | enum('1','2','3','4','5') | YES | | 1 | |
| IdChef | int(7) unsigned | YES | MUL | NULL | |
+--------+---------------------------+------+-----+---------+-------+
5 rows in set (0.00 sec)
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 59 de 71

 Criar a tabela Pratos Especiais - PEs - C3


CRIANDO AS TABELAS C3
mysql> Create table PEs (
-> IdPE int(3) unsigned not null,
-> NomePE char(40) not null,
-> DescrPE varchar(100),
-> NivelPE enum('1', '2', '3', '4', '5') default '1',
-> ValorPE decimal(7,2) unsigned,
-> DataLctoPE Date,
-> IdRPE int(7) unsigned not null,
-> constraint PkPE PRIMARY KEY (IdPE),
-> constraint FkPE FOREIGN KEY (IdRPE) REFERENCES Restaurantes (IdR)
-> ON UPDATE CASCADE ON DELETE NO ACTION )Type=InnoDB;
Query OK, 0 rows affected, 1 warning (0.13 sec)

mysql> desc PEs;


+------------+---------------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------+---------------------------+------+-----+---------+-------+
| IdPE | int(3) unsigned | NO | PRI | NULL | |
| NomePE | char(40) | NO | | NULL | |
| DescrPE | varchar(100) | YES | | NULL | |
| NivelPE | enum('1','2','3','4','5') | YES | | 1 | |
| ValorPE | decimal(7,2) unsigned | YES | | NULL | |
| DataLctoPE | date | YES | | NULL | |
| IdRPE | int(7) unsigned | NO | MUL | NULL | |
+------------+---------------------------+------+-----+---------+-------+
7 rows in set (0.02 sec)

 Criar a tabela Restaurantes Pratos Comuns - RESTPCs - C3

mysql> Create Table RESTPCs (


-> IdRPC Int(7) unsigned not null,
-> IdPCR Int(3) unsigned not null,
-> DescrRPC Varchar(100),
-> NivelRPC enum(‘1’, ‘2’, ‘3’, ‘4’, ‘5’) default ‘3’,
-> ValorRPC Decimal(7,2) unsigned,
-> Constraint PkRPC PRIMARY KEY (IdR, IdPC),
-> Constraint FkRPC FOREIGN KEY (IdR) REFERENCES Restaurantes(IdR)
-> ON UPDATE CASCADE ON DELETE NO ACTION,
-> Constraint FkPCR FOREIGN KEY (IdPC) REFERENCES PCs(IdPC)
-> ON UPDATE CASCADE ON DELETE NO ACTION
-> ) Type = Innodb;
Query OK, 0 rows affected, 1 warning (0.11 sec)
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 60 de 71

Inserir os dados abaixo na tabela Restaurantes:

IdR NomeR EnderR NivelR IdRespR


101 Restaurante Frangão 101 Rua do Frangão 101 3 2101
102 Restaurante Macarrão 102 Rua do Macarrone s/n 4 2102

Inserir os dados abaixo na tabela Restaurantes:

IdPE NomePE DescrPE NivelPE ValorPE IdRPE


1 Polentina Xpecial Polenta de abóboras 4 55.00 102

 EXERCÍCIOS PROPOSTOS EM SALA DE AULA:

1) Listar NomeR e NomePe correspondentes em ordem crescente de NomeR

SELECT NOMER, NOMEPE


FROM RESTAURANTES INNER JOIN PES
ON IDR = IDRPE ORDER BY NOMER ;
Registros: 3

NomeR NomePE
Restaurante Frangão 101 Macarrão Tomato
Restaurante Macarrão 102 Polentina Xpecial
Restaurante Macarrão 102 Arroz com Amendoas

2) Listar NomeR, NomePE, IdChef e NomeChef correspondentes em ordem


crescente de NomeChef

SELECT NOMER, NOMEPE, C.IDCHEF, NOMECHEF FROM RESTAURANTES R


INNER JOIN PES ON IDR = IDRPE INNER JOIN CHEFES C ON R.IDCHEF =
C.IDCHEF ORDER BY NOMECHEF ;
Registros: 3

NomeR NomePE IdChef NomeChef


Restaurante Frangão 101 Macarrão Tomato 101 Chefe 101
Restaurante Macarrão 102 Polentina Xpecial 102 Chefe 102
Restaurante Macarrão 102 Arroz com Amendoas 102 Chefe 102

3) Listar NomeChef (1) e NomeChef (2) formando todas as duplas de Chefes


possíveis sem repetir valores

Resultado SQL
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 61 de 71

SELECT C1.NOMECHEF 'CHEFE1', C2.NOMECHEF 'CHEFE2'


FROM CHEFES C1 INNER JOIN CHEFES C2
ON C1.IDCHEF < C2.IDCHEF;
Registros: 10

Chefe1 Chefe2
Chefe 101 Chefe 102
Chefe 101 Chefe 103
Chefe 102 Chefe 103
Chefe 101 Chefe 104
Chefe 102 Chefe 104
Chefe 103 Chefe 104
Chefe 101 Chefe 105
Chefe 102 Chefe 105
Chefe 103 Chefe 105
Chefe 104 Chefe 105

4) Listar NomeR, NomePC de todos os pratos comuns lançados no ano 2009

SELECT NOMER, NOMEPC, DATALCTOPC


FROM RESTAURANTES R INNER JOIN RPCS
ON R.IDR = RPCS.IDR
INNER JOIN PCS
ON RPCS.IDPC = PCS.IDPC
WHERE YEAR(DATALCTOPC) = 2009;

Registros: 2
NOMER NOMEPC DATALCTOPC
Restaurante Frangão 101 Arroz com feijão preto 2009-04-01
Restaurante Macarrão 102 Arroz com feijão preto 2009-04-01
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 62 de 71

5) Listar todos os NomeR e NomePE correspondentes cujo PE tenha sido lançado


no segundo semestre de 2010.

SELECT NOMER, NOMEPE, DATALCTOPE


FROM RESTAURANTES INNER JOIN PES
ON (IDR = IDRPE
AND YEAR(DATALCTOPE) = 2010)
AND MONTH(DATALCTOPE) >= '07';
Registros: 1

NOMER NOMEPE DATALCTOPE


Restaurante Frangão 101 Macarrão Tomato 2010-07-14

6) Listar todos os registros de Pratos Especiais PEs

SELECT * FROM PES LIMIT 0, 30 ;


Registros: 5
IdPE NomePE DescrPE NivelPE ValorPE IdRPE DataLctoPE
1 Polentina Xpecial Polenta de abóboras 4 55.00 102 2010-05-10
2 Macarrão Tomato Macarrão ao molho de tomate 2 39.00 101 2010-07-14
Arroz com
3 Arroz com Amendoas 3 30.00 102 2009-08-26
Amendoas
Lasagna Lasagna com molho à
4 3 79.00 101 2009-08-25
Bolognesa Bolognesa
Filet ao molho Medalhões de Filet mal-
5 4 58.00 105 2009-03-26
savignon passados ao molho

 EXEMPLOS DE QUERIES DE GRUPOS (AGRUPAMENTO):

1. Liste o maior valor de Prato Especial:


SELECT Max(ValorPE) ‘Prato Especial Mais Caro’ FROM PEs;
Registros: 1
Prato Especial Mais Caro
79.00

2. Selecione o Preço Médio de todos os Pratos Especiais:


SELECT AVG(ValorPE) ‘Preço Médio dos Pratos Especiais’ FROM PEs;
Registros: 1
Preço Médio dos Pratos Especiais
52.20
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 63 de 71

3. Liste o código do restaurante com o nome do seu Prato Especial de


maior valor:
SELECT IdRPE 'Restaurante', NomePe 'Prato', Max(ValorPE)MaiorPreço
FROM PEs
GROUP BY IdRPE
ORDER BY IdRPE;
Registros: 3
Restaurante Prato MaiorPreço
101 Macarrão Tomato 79.00
102 Polentina Xpecial 55.00
105 Filet ao molho savignon 58.00

4. Liste o código do restaurante com o Preço Médio de seus Pratos


Especiais:
SELECT IdRPE 'Restaurante', AVG(ValorPE) PreçoMédio
FROM PEs
GROUP BY IdRPE
ORDER BY IdRPE;
Registros: 3
Restaurante PreçoMédio
101 [->] 59.000000
102 [->] 42.500000
105 [->] 58.000000

5. Liste o nome do restaurante, o nome e valor do prato de maior preço


de seus Pratos Especiais:
1a. Tentativa
Select NomeR 'Restaurante', NomePE 'Prato', max(valorpe) MaiorValor
From Restaurantes Inner Join PÉS
On IdR = IdRPE;
Registros: 1
Restaurante Prato MaiorValor
Restaurante Macarrão 102 Polentina Xpecial 79.00
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 64 de 71

2a. Tentativa

Select NomeR 'Restaurante', NomePE 'Prato', max(valorpe) MaiorValor


From Restaurantes Inner Join PEs
On idr = idrpe
Group By idrpe;
Registros: 3

Restaurante Prato MaiorValor


Restaurante Frangão 101 Macarrão Tomato 79.00
Restaurante Macarrão 102 Polentina Xpecial 55.00
Restaurante Bandeirantes Filet ao molho savignon 58.00

3. SELECT NOMEPE PRATO, VALORPE VALOR


FROM PES
WHERE VALORPE < (SELECT AVG(VALORPE) FROM PES);
Registros: 2
Prato Valor
Macarrão Tomato 39.00
Arroz com Amendoas 30.00

4. SELECT NomePE Prato, ValorPE Valor


FROM PEs Where ValorPE >= (Select AVG(ValorPE) from PEs);
Registros: 3
Prato Valor
Polentina Xpecial 55.00
Lasagna Bolognesa 79.00
Filet ao molho savignon 58.00

5. Select P1.NomePE Prato, P1.ValorPE Valor, NomeR Restaurante


FROM PEs P1 inner join Restaurantes R
ON P1.IdRPE = R.IdR
Where P1.ValorPE >= (Select AVG(ValorPE) from PEs);
Registros: 3
Prato Valor Restaurante
Lasagna Bolognesa 79.00 Restaurante Frangão 101
Polentina Xpecial 55.00 Restaurante Macarrão 102
Filet ao molho savignon 58.00 Restaurante Bandeirantes
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 65 de 71

 Selecionando os iguais:
SELECT NomeR, NomePE
From Restaurantes inner join PEs
on IdRPE = IdR;

Registros: 1

NomeR NomePE
Restaurante Macarrão 102 Polentina Xpecial

 Selecionando também os desiguais:


SELECT NomeR, NomePE
From Restaurantes left join PEs
on IdRPE = IdR;

Registros: 2

NomeR NomePE
Restaurante Frangão 101 NULL
Restaurante Macarrão 102 Polentina Xpecial

 Exercícios da aula de 26/10/10 do AS43-B

1 - Gere uma consulta que liste os restaurantes com a quantidade de PEs


(pratos especiais) correspondentes.

SELECT nomeR , COUNT(IdrPE)


FROM Restaurantes INNER JOIN PEs
ON IdR = IdrPE
GROUP BY IdR

SELECT NomeR RESTAURANTE, COUNT(IdrPE) 'PRATOS ESPECIAIS'


FROM Restaurantes INNER JOIN PEs
ON IdR = IdrPE
GROUP BY IdR;
Registros: 3

RESTAURANTE PRATOS ESPECIAIS


Restaurante Frangão 101 2
Restaurante Macarrão 102 2
Restaurante Bandeirantes 1
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 66 de 71

2 - Gere uma consulta que apresente os restaurantes (nome) com o


somatórios dos valores de seus PEs.

SELECT nomeR , SUM(ValorPE)


FROM Restaurantes INNER JOIN PEs
ON IdR = IdrPE
GROUP BY IdR

SELECT nomeR RESTAURANTE, SUM(ValorPE) 'SOMA DE VALOR'


FROM Restaurantes INNER JOIN PEs
ON IdR = IdrPE GROUP BY IdR;
Registros: 3

RESTAURANTE SOMA DE VALOR


Restaurante Frangão 101 118.00
Restaurante Macarrão 102 85.00
Restaurante Bandeirantes 58.00

3 - Liste todos os restaurantes e seus respectivos PEs cujo preço é maior que
o preço médio de todos os PEs (ValorPE).

SELECT nomeR , NomePE, ValorPE


FROM Restaurantes INNER JOIN PEs
ON IdR = IdrPE
WHERE ValorPE >
( SELECT AVG(ValorPE) FROM PEs)

SELECT AVG(ValorPE) 'VALOR MÉDIO DO PRATO ESPECIAL'


FROM PEs;
Registros: 1
VALOR MÉDIO DO PRATO ESPECIAL
52.200000

SELECT nomeR , NomePE, ValorPE


FROM Restaurantes INNER JOIN PEs
ON IdR = IdrPE WHERE ValorPE > ( SELECT AVG(ValorPE) FROM PEs) ;
Registros: 3
nomeR NomePE ValorPE
Restaurante Macarrão 102 Polentina Xpecial 55.00
Restaurante Frangão 101 Lasagna Bolognesa 79.00
Restaurante Bandeirantes Filet ao molho savignon 58.00
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 67 de 71

4 - Liste NomeR, NomePE, PrecoPE, e Preço médio dos Pes.

SELECT nomeR , NomePE, ValorPE , ( SELECT AVG(ValorPE) FROM PEs) ValorMedio


FROM Restaurantes INNER JOIN PEs
ON IdR = IdrPE

SELECT nomeR , NomePE, ValorPE , ( SELECT AVG(ValorPE) FROM PEs) ValorMedio


FROM Restaurantes INNER JOIN PEs
ON IdR = IdrPE ;
Registros: 5
nomeR NomePE ValorPE ValorMedio
Restaurante Macarrão 102 Polentina Xpecial 55.00 52.200000
Restaurante Frangão 101 Macarrão Tomato 39.00 52.200000
Restaurante Macarrão 102 Arroz com Amendoas 30.00 52.200000
Restaurante Frangão 101 Lasagna Bolognesa 79.00 52.200000
Restaurante Bandeirantes Filet ao molho savignon 58.00 52.200000

Ordenando por Nome do restaurante:

SELECT NomeR , NomePE, ValorPE , ( SELECT AVG(ValorPE) FROM PEs)


ValorMedio FROM Restaurantes INNER JOIN PEs
ON IdR = IdrPE
ORDER BY NomeR ;
Registros: 5
nomeR NomePE ValorPE ValorMedio
Restaurante Bandeirantes Filet ao molho savignon 58.00 52.200000
Restaurante Frangão 101 Lasagna Bolognesa 79.00 52.200000
Restaurante Frangão 101 Macarrão Tomato 39.00 52.200000
Restaurante Macarrão 102 Arroz com Amendoas 30.00 52.200000
Restaurante Macarrão 102 Polentina Xpecial 55.00 52.200000

Colaboração de Alessandra Candido


DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 68 de 71

 CRIAR PROCEDURES E FUNÇÕES NO MYSQL

CREATE PROCEDURE sp_name ([parameter[,...]])


[characteristic ...] routine_body

CREATE FUNCTION sp_name ([parameter[,...]])


[RETURNS type]
[characteristic ...] routine_body

parameter:
[ IN | OUT | INOUT ] param_name type

type:
Any valid MySQL data type

characteristic:
LANGUAGE SQL
| [NOT] DETERMINISTIC
| SQL SECURITY {DEFINER | INVOKER}
| COMMENT string

routine_body:
Valid SQL procedure statement(s)

A cláusula RETURNS pode ser especificada apenas por uma FUNCTION. É usada para indicar o
tipo de retorno da função, e o corpo da função deve conter uma instrução RETURN value.

A lista de parâmetros entre parenteses deve estar sempre presente. Se não houver
parâmetros, uma lista de parâmetros vazia de () deve ser usada. Cada parâmetro é um
parâmetro IN por padrão. Para especificar outro tipo de parâmetro, use a palavra chave OUT
ou INOUT antes do nome do parâmetro. Especificar IN, OUT ou INOUT só é valido para uma
PROCEDURE.

A instrução CREATE FUNCTION é usada em versão novas do MySQL para suporte a UDFs (User
Defined Functions - Funções Definidas pelo Usuário). See Secção 14.2, “Adicionando Novas
Funções ao MySQL”. As UDFs continuam a ser suportadas, mesmo com a existencia de stored
functions. Uma UDF pode ser considerada como uma stored function externa. No entanto, note
que stored functions compartilham os seus namespace com as UDFs.

Um framework para stored procedures externas serão introduzidas em um futuro próxima. Isto
permitirá que você escreva stored procedures em outras linguagens além de SQL.
Provavelmente, uma das primeiras linguagens a ser suportada sea PHP, já que o mecanismo
do PHP é pequeno, seguro com threads e pode facilmente ser embutido. Como o framework
será publico, é esperado que muitas outras linguagens também sejam suportadas.

Uma função é considerada ``deterministica'' se ela sempre retorna o mesmo resultado para os
mesmos parâmetros de entrada, e ``não deterministica'' caso contrário. O otimizado pode
usar este fato. Atualmente, a característica DETERMINISTIC é aceita, mas ainda não é usada.
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 69 de 71

A característica SQL SECURITY pode ser usada para especificar se a rotina deve ser executada
usando as permissões do usuário que criou a rotina, ou o usuário que a chamou. O valor
padrão é DEFINER. Este recurso é novo no SQL:2003.

O MySQL ainda não usa o privilégio GRANT EXECUTE. Assim ,por enquanto, se um
procedimento p1() chama a tabela t1,o usuário deve ter privilégios na tabela t1 para chamar o
procedimento p1() com sucesso.

MySQL stores the SQL_MODE settings in effect at the time a routine is created, and will always
execute routines with these settings in force.

A cláusula COMMENT é uma extensão do MySQL, e pode ser usada para descrever o stored
procedure. Esta informação é exibida pelas instruções SHOW CREATE PROCEDURE e SHOW
CREATE FUNCTION.

O MySQL permite rotinas contendo instruções DDL (como CREATE e DROP) e instruções de
transação SQL (como COMMIT). Isto não é exigido por padrão e depende de especificações de
implementação.

NOTA: Atualmente, stored FUNCTIONs não podem conter referências às tabelas. Note que isto
inclui algumas instruções SET, mas exclui algumas instruções SELECT. Esta limitação será
retirada assim que possível.

A seguir temos um exemplo de uma stored procedure simples que usa um parâmetro OUT. O
exemplo usa o comando delimiter do cliente mysql para alterar o delimitador de instrução para
antes da definição do procedure. Isto permite que o delimitador ‘;’ usado no corpo de
procedure seja passado para o servidor em vez de ser interpretado pelo mysql.

mysql> delimiter |

mysql> CREATE PROCEDURE simpleproc (OUT param1 INT)


-> BEGIN
-> SELECT COUNT(*) INTO param1 FROM t;
-> END
-> |
Query OK, 0 rows affected (0.00 sec)

mysql> CALL simpleproc(@a)|


Query OK, 0 rows affected (0.00 sec)

mysql> SELECT @a|


+------+
| @a |
+------+
|3 |
+------+
1 row in set (0.00 sec)

A seguir esta um exemplo de uma função que utiliza um parametro, realiza uma operação
usando uma função SQL e retorna o resultado:
DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 70 de 71

mysql> delimiter |

mysql> CREATE FUNCTION hello (s CHAR(20)) RETURNS CHAR(50)


-> RETURN CONCAT('Hello, ',s,'!');
-> |
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT hello('world')|


+----------------+
| hello('world') |
+----------------+
| Hello, world! |
+----------------+
1 row in set (0.00 sec)

ALTERAR PROCEDURE E FUNCTION

ALTER PROCEDURE | FUNCTION sp_name [characteristic ...]


characteristic:
NAME newname
| SQL SECURITY {DEFINER | INVOKER}
| COMMENT string
Este comando pode ser usado para renomear uma stored procedure ou function, e para alterar
suas características. Mais de uma mudança pode ser especificada em uma instrução ALTER
PROCEDURE ou ALTER FUNCTION.

EXCLUIR PROCEDURE E FUNCTION


DROP PROCEDURE | FUNCTION [IF EXISTS] sp_name
Este comando é usado para deletar uma stored procedure ou function. Isto é, a
rotina especificada é removida do servidor.
A cláusula IF EXISTS é uma extensão do MySQL. Ela previne que um erro ocorra se
o procedimento ou função não existe. Um aviso é produzido e pode ser vizualizado
com SHOW WARNINGS.

Extraído do Manual de Referência do MySQL 4.1


DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS
Prof. Sérgio AGNELLO Pág. 71 de 71

select NomeR, ValorPE


from restaurantes inner join PEs
on idr = idrpe
where valorpe >= (select avg(valorpe)from pes where idrpe = idr) ;
Registros: 3

NomeR ValorPE
Restaurante Macarrão 102 55.00
Restaurante Frangão 101 79.00
Restaurante Bandeirantes 58.00

select nomer, valorpe, (select avg(valorpe)from pes where idrpe = idr) 'Valor Médio'
from restaurantes inner join pes
on idr = idrpe
order by idr;
Registros: 5

nomer valorpe Valor Médio


Restaurante Frangão 101 79.00 59.000000
Restaurante Frangão 101 39.00 59.000000
Restaurante Macarrão 102 55.00 42.500000
Restaurante Macarrão 102 30.00 42.500000
Restaurante Bandeirantes 58.00 58.000000