## ADB e SQL Por Sergio Agnello Paschoal - Até Pag 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 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).
 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
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.
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.
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.
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;}

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
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 }
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 }

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
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
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.
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
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.
 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.
 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.

 TELAS DO GERENCIADOR PHP MyADMIN

 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.
 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> DROP DATABASE MAPAS;

QUERY OK, 2 ROWS AFFECTED (0.16 SEC)
MYSQL>
 RECRIANDO O BANCO DE DADOS DE NOME MAPAS

MYSQL> DROP DATABASE MAPAS;
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>
 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.
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
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
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
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
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;
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
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

NotaAlu Nr Decimal(4,2)
Tabela DiasLetivosDeAlunosDeMCA – Secundária – C4

DT Data, Não Nulo, Chave Primária,
Fi bool (verdadeiro ou falso)
 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));
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.
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
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

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.
 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

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>
mysql> create table Professores (

-> CodProf int unsigned not null,
-> NomeProf varchar(30),
-> TelProf varchar(15),
-> constraint PkProf primary key (CodProf) ) ;
mysql> desc Professores;

+----------+--------------------+-------+--------+---------+-------+
+----------+--------------------+-------+--------+---------+-------+
| CodProf | int(10) unsigned | NO | PRI | NULL | |
| NomeProf | varchar(30) | YES | | NULL | |
| TelProf | varchar(15) | YES | | NULL | |
+----------+--------------------+-------+--------+---------+-------+
mysql> show tables;

+----------------------+
| Tables_in_mapas |
+----------------------+
| materias |
| professores |
+----------------------+
mysql> create table Alunos (

-> MatricAlu int unsigned not null,
-> NomeAlu varchar(30) not null,
-> Constraint PkAlu primary key (MatricAlu) ) ;
mysql> show tables;

+--------------------------+
| Tables_in_mapas |
+--------------------------+
| alunos |
| materias |
| professores |
+--------------------------+
mysql>
 CRIANDO AS TABELAS SECUNDÁRIAS (C2, C3 E C4)
Tabela MCA – Secundária – C2

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

NotaAlu Nr Decimal(4,2)
Tabela DiasLetivosDeAlunosDeMCA – Secundária – C4

Abreviando para DiasLetivos
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) ) ;

mysql> show tables;

+-----------------+
| Tables_in_mapas |
+-----------------+
| alunos |
| materias |
| mca |
| professores |
+-----------------+
mysql> desc mca;

+---------+---------------------+------+-----+---------+-------+
+---------+---------------------+------+-----+---------+-------+
| 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 | |
+---------+---------------------+------+-----+---------+-------+
mysql> Create Table AlunosMCA (

-> NotaAlu decimal(4,2),
-> Constraint PkAlunosMCA Primary Key (CodMCA, MatricAlu),
-> Constraint FkAlunosMCA Foreign Key (MatricAlu) References Alunos (MatricAlu));
mysql> desc AlunosMCA;

+-----------+-------------------+------+------+---------+----------+
+-----------+-------------------+------+------+---------+----------+
| MatricAlu | int(10) unsigned | NO | PRI | NULL | |
| NotaALu | decimal(4,2) | YES | | NULL | |
+-----------+-------------------+------+------+---------+----------+
mysql> Create table DiasLetivos (  simplificando para DiasLet )

-> DT date not null,
-> Fi bool,
-> constraint PkDiasLetivos Primary Key (CodMCA, MatricAlu, DT),
-> constraint FkDiasLetivos Foreign Key (CodMCA, MatricAlu) References
AlunosDeMCA (CodMCA, MatricAlu));
 CRIANDO E VERIFICANDO A TABELA DIASLETIVOS

mysql> Create Table DiasLet (
-> Dt date not null,
-> Fi bool,
-> Constraint PkDiasLet Primary Key (CodMCA, MatricAlu, Dt),
-> Constraint FkDiasLet Foreign Key (CodMCA, MatricAlu) References AlunosMCA
(CodMCA, MatricAlu));
mysql> desc DiasLet;

+----------+--------------------+------+--------+----------+---------+
+----------+--------------------+------+--------+----------+---------+
| MatricAlu| int(10) unsigned | NO | PRI | NULL | |
| DT | date | NO | PRI | NULL | |
| Fi | tinyint(1) | YES | | NULL | |
+----------+--------------------+------+--------+----------+---------+
 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
Records: 0 Duplicates: 0 Warnings: 0
mysql> desc Alunos;

+-----------+---------------------+-------+------+---------+-------+
+-----------+---------------------+-------+------+---------+-------+
| NomeAlu | varchar(30) | NO | | NULL | |
| SexoAlu | enum('M','F') | YES | | NULL | |
+-----------+---------------------+-------+------+---------+-------+
 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;
mysql> desc alunos;

+--------------+-------------------------+-------+--------+------------+----------+
+--------------+-------------------------+-------+--------+------------+----------+
| NomeAlu | varchar(30) | NO | | NULL | |
| SexoAlu | enum('M','F') | NO | | NULL | |
+--------------+------------------------+--------+--------+------------+----------+
 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)

-> Values ('123457', 'Bastiana Brejão', 'F');
mysql> select * from Alunos;

+-----------------+-----------------------------+-------------+
| MatricAlu | NomeAlu | SexoAlu |
+-----------------+-----------------------------+-------------+
| 123456 | Abelardo Barbosa | M |
| 123457 | Bastiana Brejão |F |
+-----------------+-----------------------------+--------------+
 RETOMANDO A SESSÃO:
Agnello@PAVILION C:\Xampp
# cd mysql\bin
Agnello@PAVILION C:\Xampp\mysql\bin
# mysql -u root -p
Enter password:
mysql> use mapas

Database changed
mysql> show tables ;

+-------------------------+
| Tables_in_mapas |
+-------------------------+
| alunos |
| alunosmca |
| diaslet |
| materias |
| mca |
| professores |
+--------------------------+
 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;

+--------------+--------------------------------+------------+
+--------------+--------------------------------+------------+
| 123457 | Bastiana Brejão | F |
| 123458 | Aluno Oito | M |
| 123459 | Aluna Nove | F |
| 123460 | Aluno Sessenta | M |
| 123461 | Aluna Sessenta e Hum | F |
+--------------+--------------------------------+------------+
 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:

-> 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');

mysql> SELECT * FROM ALUNOS;

+------------+------------------------+------------+
+------------+------------------------+------------+
| 123458 | Aluno Oito | M |
| 123459 | Aluna Nove | F |
| 123471 | Aluno Setenta e Hum | M |
| 123472 | Aluna Setenta e Dois | F |
| 123474 | Aluno Setenta e Quatro | M |
+------------+------------------------+------------+

-> Values ('123473', 'Aluna Setenta e Três', 'F');

+------------+------------------------+---------+
+------------+------------------------+---------+
| 123458 | Aluno Oito | M |
| 123459 | Aluna Nove | F |
| 123473 | Aluna Setenta e Três | F |
+------------+------------------------+---------+

-> Values ('1', 'Aluno Número Um', 'M');
mysql> Select * from Alunos order by NomeAlu;

+-------------+--------------------------+---------+
+-------------+--------------------------+---------+
| 123459 | Aluna Nove | F |
| 1 | Aluno Número Um | M |
| 123458 | Aluno Oito | M |
+-------------+--------------------------+---------+
 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
# cd mysql\bin
# mysql -u root -p
Enter password:
mysql> use mapas

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

mysql> desc alunos;

+-----------------+-----------------------------+----------------+----------+--------------+-----------+
| Field | Type | Null | Key | Default | Extra | |
+-----------------+-----------------------------+----------------+----------+---------------+----------+
| NomeAlu | varchar(30) | NO | MUL | NULL | |
| SexoAlu | enum('M','F') | NO | | NULL | |
+-----------------+-----------------------------+----------------+----------+---------------+----------+
mysql> select * from Alunos

-> Order by NomeAlu;
+-------------+-------------------------------------------+------------+
+-------------+-------------------------------------------+------------+
| 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;

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 |
| 123457 | BASTIANA BREJ?O | F |
+-----------------+-------------------------------------------+---------------+
MYSQL> CREATE INDEX IDXNOMEALU ON ALUNOS (NOMEALU(10) DESC);


-> ORDER BY NOMEALU DESC;
+-------------------+-------------------------------------------------+---------------+
+-------------------+-------------------------------------------------+---------------+
| 123457 | BASTIANA BREJAO | F |

| 123459 | ALUNA NOVE | F |
+-----------------+----------------------------------------------------+-----------+
MYSQL> DROP INDEX IDXNOMEALU ON ALUNOS;


-> ORDER BY NOMEALU DESC;
+-----------------+---------------------------------------------------+---------------+
+-----------------+---------------------------------------------------+---------------+
| 123457 | BASTIANA BREJAO | F |
| 123459 | ALUNA NOVE | F |
+-----------------+----------------------------------------------------+---------------+
 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
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
 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 |
+---------+---------------------+----------------+
mysql>
 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;
Rows matched: 1 Changed: 1 Warnings: 0

+------------+------------------------+----------+
+------------+------------------------+----------+
| 123458 | Aluno Oito da Silva | M |
| 123459 | Aluna Nove | F |
| 1 | Aluno Número Um | M |
+------------+------------------------+----------+
 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;

 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
# CD MYSQL\BIN
# mysql -u root -p
Enter password:
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');
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 |
+-----------+------------+---------+---------+
 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
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;
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
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
(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.
 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.
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.
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:

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;

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
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
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...
 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 |
+----+---------+--------+
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 |
+---------+------------+
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 |
+---------+------------+
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 |
| NULL | Ana | NULL |

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

-> on cliente.codigo=pedido.cliente;
+--------------+
| count(valor) |
+--------------+
| 5 |
+--------------+
mysql> select count(*) from cliente left join pedido on

cliente.codigo=pedido.cliente;
+----------+
| count(*) |
+----------+
| 12 |
+----------+
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 |
+----+---------+--------+
mysql> select min(valor) from pedido;

+------------+
| min(valor) |
+------------+
| 50.50 |
+------------+
mysql> select max(valor) from pedido;

+------------+
| max(valor) |
+------------+
| 100.05 |
+------------+
mysql> select sum(valor) from pedido;

+------------+
| sum(valor) |
+------------+
| 346.15 |
+------------+
 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
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:
# cd mysql\bin
# mysql -u root -p
Enter password:
mysql> create database BDRest;

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',
-> 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;
mysql> desc PCs;

+--------+-----------------+------+-----+---------+-------+
+--------+-----------------+------+-----+---------+-------+
| IdPC | int(3) unsigned | NO | PRI | NULL | |
| NomePC | char(40) | NO | | NULL | |
+--------+-----------------+------+-----+---------+-------+
mysql>
 Criar a tabela Restaurantes - 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;
mysql> Desc Restaurantes;

+--------+---------------------------+------+-----+---------+-------+
+--------+---------------------------+------+-----+---------+-------+
| 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 | |
+--------+---------------------------+------+-----+---------+-------+
 Criar a tabela Pratos Especiais - PEs - 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;
mysql> desc PEs;

+------------+---------------------------+------+-----+---------+-------+
+------------+---------------------------+------+-----+---------+-------+
| 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 | |
+------------+---------------------------+------+-----+---------+-------+
 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;
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
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
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
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
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 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
 Selecionando os iguais:
SELECT NomeR, NomePE
From Restaurantes inner join PEs
on IdRPE = IdR;
Registros: 1
NomeR NomePE
 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
 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'

ON IdR = IdrPE
GROUP BY IdR;
Registros: 3
RESTAURANTE PRATOS ESPECIAIS

Restaurante Frangão 101 2
Restaurante Macarrão 102 2
Restaurante Bandeirantes 1
2 - Gere uma consulta que apresente os restaurantes (nome) com o

somatórios dos valores de seus PEs.
SELECT nomeR , SUM(ValorPE)

ON IdR = IdrPE
GROUP BY IdR
SELECT nomeR RESTAURANTE, SUM(ValorPE) 'SOMA DE VALOR'

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

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

ON IdR = IdrPE WHERE ValorPE > ( SELECT AVG(ValorPE) FROM PEs) ;
Registros: 3
nomeR NomePE ValorPE
Restaurante Frangão 101 Lasagna Bolognesa 79.00
Restaurante Bandeirantes Filet ao molho savignon 58.00
4 - Liste NomeR, NomePE, PrecoPE, e Preço médio dos Pes.
SELECT nomeR , NomePE, ValorPE , ( SELECT AVG(ValorPE) FROM PEs) ValorMedio

ON IdR = IdrPE
SELECT nomeR , NomePE, ValorPE , ( SELECT AVG(ValorPE) FROM PEs) ValorMedio

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

 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.
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
-> |
mysql> CALL simpleproc(@a)|

mysql> SELECT @a|

+------+
| @a |
+------+
|3 |
+------+
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:
mysql> delimiter |
mysql> CREATE FUNCTION hello (s CHAR(20)) RETURNS CHAR(50)

-> RETURN CONCAT('Hello, ',s,'!');
-> |
mysql> SELECT hello('world')|

+----------------+
| hello('world') |
+----------------+
| Hello, world! |
+----------------+
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

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

## ADB e SQL Por Sergio Agnello Paschoal - Até Pag 71

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

## ADB e SQL Por Sergio Agnello Paschoal - Até Pag 71

Enviado por

Direitos autorais:

Formatos disponíveis

DISCIPLINA: ADMINISTRAÇÃO DE BANCOS DE DADOS

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

 Conteúdo previsto de aulas

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

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

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

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

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

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

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

1 12 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 17 3 Modelagem lógica. Formas normais (até a 3° forma normal)

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

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 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 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.

14. MODELO DE DADOS RELACIONAL

14.1 NOTAÇÃO DE RELAÇÃO

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

14.2 O PROCESSO DE NORMALIZAÇÃO

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

14.3 CONCEITOS ESSENCIAIS

14.4 CONCEITOS ADICIONAIS

DF – DEPENDÊNCIA FUNCIONAL IRREDUTÍVEL À ESQUERDA

14.5 ALGUNS SÍMBOLOS FAZEM PARTE DO MODELO RELACIONAL:

14.6 DEPENDÊNCIAS FUNCIONAIS - DF

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

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

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

14.8 SUA EXCELÊNCIA O SGBDR:

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

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

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

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

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

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

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

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

 MCA II – Mapa Controle de Aulas II

MCA Data: ____/______/__________.

Alunos (1 – 50) Dias Letivos

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

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

DiasLetivosDeAlunosDeMCA { CodMCA; MatricAlu; DT; Fi;}

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

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

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

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

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

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

MCA Data: //________.