Você está na página 1de 220

SISTEMA DE GERENCIAMENTO

DE BANCO DE DADOS
RELACIONAL
Charles Emerson Machado

Charles.emerson.machado@gmail.com

1
INFORMAÇÃO - É o valor que este campo representa para as atividades da
empresa. Ex. Resposta a uma consulta. Qual os nomes do clientes localizados
no Rio de Janeiro?

DADO - É o valor do campo quando é armazenado no Banco de Dados. Ex. O


valor do campo "nome do cliente" para quem está fazendo a entrada de dados.

CONTEÚDO DO CAMPO - É o valor do campo armazenado no Banco de


Dados. Ex. O valor do campo "nome do cliente" sem ser, momentaneamente,
utilizado, armazenado na Base de Dados.

MODELOS DE BANCO DE DADOS - Modelo Relacional, Modelo Hierárquico e


Modelo em Rede. Representa a estrutura física no qual o armazenamento dos
dados foram projetados. O modelo identifica a estrutura interna de recuperação
e armazenamento dos dados no qual o SGBD foi projetado.

2
O que é um banco de dados?

Uma coleção de dados relacionados referentes a um mesmo assunto e


organizados de maneira útil com o propósito de servir de base para que o usuário
recupere informações, tire conclusões e tome decisões.

3
Bancos de Dados começaram a ser utilizados por volta
dos anos 60 e em 70 E.F. Codd da IBM publicou o artigo
“Um Modelo Relacional de Dados para Grandes Bancos
de Dados Compartilhados” estabelecendo princípios sobre
gerência de banco de dados, surgindo então a linguagem
SQL (Structured Query Language ou Linguagem de
Consulta Estruturada) inicialmente chamada de SEQUEL
(Structured English Query Language).

Conheça mais o trabalho do Dr. Codd em


www.informatik.uni-trier.de/%7Eley/db/about/codd.html

4
Década de 70

Muitas discussões a respeito do valor da competição entre os sistemas enquanto


a teoria de banco de dados conduz ao objetivo final de projeto de pesquisa. Dois
principais protótipos de sistema relacional foram desenvolvidos entre 1974 e
1977 e demonstram um ótimo exemplo de como a teoria conduz a boas práticas.

• Ingres: Desenvolvido pela UCB. Que no final das contas serviu como base
para Ingres Corp., Sybase, MS SQL Server, Britton-Lee, Wang PACE. Este
sistema utilizava QUEL como linguagem de consulta;

• System R: Desenvolvido pela IBM San Jose e serviu de base para o IBM
SQL/DS, IBM DB2, Oracle, todas os BD da HP, Tandem's Non-Stop SQL. Este
sistema utilizava SEQUEL como linguagem de consulta.

O termo Sistema de Gerenciamento de Banco de Dados Relacional (SGBDR –


RDBMS em inglês) foi definido durante este período.

5
1976
O Dr. Peter Chen (visite bit.csc.lsu.edu/~chen/chen.html
propõe o modelo Entidade-Relacionamento (ER) para projetos
de banco de dados dando uma nova e importante percepção
dos conceitos de modelos de dados. Assim como as linguagens
de alto nível, a modelagem ER possibilita ao projetista
concentrar-se apenas na utilização dos dados, sem se
preocupar com estrutura lógica de tabelas.

6
VANTAGENS DO BANCO DE DADOS

1 - REDUÇÃO OU ELIMINAÇÃO DE REDUNDÂNCIAS - Possibilita a


eliminação de dados privativos de cada sistema. Os dados, que
eventualmente são comuns a mais de um sistema, são compartilhados por
eles, permitindo o acesso a uma única informação sendo consultada por
vários sistemas.

7
2 - ELIMINAÇÃO DE INCONSISTÊNCIAS - Através do armazenamento da
informação em um único local com acesso descentralizado e, sendo
compartilhada à vários sistemas, os usuários estarão utilizando uma
informação confiável. A inconsistência ocorre quando um mesmo campo
tem valores diferentes em sistemas diferentes. Exemplo, o estado civil de
uma pessoa é solteiro em um sistema e casado em outro. Isto ocorre
porque esta pessoa atualizou o campo em um sistema e não o atualizou
em outro. Quando o dado é armazenado em um único local e
compartilhado pelos sistemas, este problema não ocorre.

8
3 - COMPARTILHAMENTO DOS DADOS - Permite a utilização
simultânea e segura de um dado, por mais de uma aplicação ou usuário,
independente da operação que esteja sendo realizada. Deve ser
observada apenas o processo de atualização concorrente, para não gerar
erros de processamento (atualizar simultaneamente o mesmo campo do
mesmo registro). Os aplicativos são por natureza multiusuário.

9
4 - RESTRIÇÕES DE SEGURANÇA - Define para cada usuário o nível de
acesso a ele concedido (leitura, leitura e gravação ou sem acesso) ao
arquivo e/ou campo. Este recurso impede que pessoas não autorizadas
utilizem ou atualizem um determinado arquivo ou campo.

10
5 - PADRONIZAÇÃO DOS DADOS - Permite que os campos armazenados
na base de dados sejam padronizados segundo um determinado formato
de armazenamento (padronização de tabela, conteúdo de campos, etc) e
ao nome de variáveis seguindo critérios padrões pré-estabelecido pela
empresa. Ex. Para o campo "Sexo" somente será permitido
armazenamento dos conteúdos "M" ou "F".

11
6 - MANUTENÇÃO DE INTEGRIDADE - Exige que o conteúdo dos dados
armazenadas no Banco de Dados possuam valores coerentes ao objetivo
do campo, não permitindo que valores absurdos sejam cadastrados.
Exemplo: Um funcionário que faça no mês 500 horas extras, ou um aluno
que tenha nascido no ano de 1860.

12
7 - EVITAR NECESSIDADES CONFLITANTES - Representa a capacidade
que o administrador de Banco de Dados deve ter para solucionar
"prioridades sempre altas" de todos os sistemas, tendo ele que avaliar a
real necessidade de cada sistema para a empresa para priorizar a sua
implantação.

13
8 - INDEPENDÊNCIA DOS DADOS - Representa a forma física de
armazenamento dos dados no Banco de Dados e a recuperação das
informações pelos programas de aplicação. Esta recuperação deverá ser
totalmente independente da maneira com que os dados estão fisicamente
armazenados. Quando um programa retira ou inclui dados o SGBD
compacta-os para que haja um menor consumo de espaço no disco. Este
conhecimento do formato de armazenamento do campo é totalmente
transparente para o usuário.

14
Modelos de Bancos de Dados

Os tipos ou modelos de banco de dados podem ser divididos de acordo


com as estruturas de dados e os operadores que apresentam ao usuário.
O modelo mais utilizado atualmente é o relacional, pois através dele os
dados podem ser percebidos pelo usuário como tabelas e os operadores
à disposição do usuário podem gerar novas tabelas a partir das tabelas
antigas.
Os sistemas que antecedem o modelo relacional são chamados de pré-
relacionais, são eles: hierárquicos e de rede. São modelos considerados
hábito e possuem uma característica comum, todos eles expõem
ponteiros para o usuário; mais recentemente foi criado o modelo orientado
a objetos que é um sistema em que a unidade de armazenamento é o
objeto.

15
Um modelo de dados é uma estrutura de referência para organizar dados,
todo SGBD deve suportar um modelo que permita uma representação dos
dados de uma realidade.
O esquema conceitual de uma aplicação é o resultado da adequação dos
requisitos de dados desta aplicação ao modelo de dados do SGBD. Todo
modelo de dados deve suportar, no mínimo, a especificação de entidades
e relacionamentos.

16
Modelo Hierárquico

Surgiu na década de 60, organizava dados em uma estrutura de Bancos


de Dados Hierárquicos. São baseados em registros compostos por
diversos campos e são organizados em forma de árvore e não em formato
de tabelas.
Os registros possuem sub-registros e assim sucessivamente, formando
uma ramificação semelhante a uma árvore. Dois registros são unidos por
um elo, um é ascendente e outro é descendente.

17
Modelo de Redes

Utilizado principalmente no final da década de 60 e durante a década de


70, organizava dados em uma estrutura formada por várias listas, que
definia uma confusa rede de ligações (estrutura similar a um grafo
direcionado).
Este tipo de gerenciador de Banco de Dados é parecido com o Modelo
Hierárquico, porém, cada registro “filho” pode ser ligado a mais de um
registro “pai”, possibilitando a formação de ligações mais complexas,
porque não há a restrição a um só tipo de relacionamento que vigora.

18
Modelo Relacional

Este modelo é utilizado por quase todos os atuais fabricantes de Banco


de Dados do mundo. Criado por Edgar Frank Codd, pesquisador da IBM
e definido na década de 70, é considerado até hoje uma das maiores
inovações técnicas do século XX.
É o modelo de dados dominante no mercado atualmente, organiza dados
em um conjunto de relações (tabelas), alem disso é o mais fácil de ser
descrito e entendido.
O Modelo Relacional consagrou – se como o primeiro modelo de dados
para aplicações comerciais. Os primeiros sistemas de Banco de Dados
tiveram por base, o modelo de rede e modelo hierárquico, esses dois
modelos antigos estão mais próximos da implementação no nível físico
que no modelo relacional.

19
No mercado existem outros tipos de sistemas, porém há um pré - domínio
dos SGBDs relacionais, principalmente fora das plataformas de grande
porte, nestes ambientes estão gradativamente substituindo o SGBD de
outras abordagens (Hierárquica, Rede, por exemplo).
Banco de Dados Relacional é um grupo de dados percebido pelos
usuários como um conjunto de tabelas. [DATE, 2000]
A terminologia “relação” foi utilizada na estrutura original devido ao fato de
que os sistemas relacionais baseiam – se num conjunto fundamental de
idéias teóricas conhecidas como modelo relacional. Essa terminologia é a
mais comum na área acadêmica.
A terminologia “ tabela” é mais comum na prática e nos produtos
comerciais.
Uma “relação” é vista como uma “tabela”, onde as colunas indicam os
campos e as linhas as ocorrências (valores). Relacionamentos entre
relações são estabelecidos por igualdade de valor de campos.

20
O que é um Banco de dados Relacional?

Num banco de dados relacional os dados são armazenados em forma


de tabelas.
Cada tabela e constituída por linhas horizontais chamadas tuplas e
verticais, chamadas colunas ou atributos. Você pode identificar cada
tabela, dando-lhes nomes únicos, e o banco de dados usa esses nomes
para acessar as tabelas.
Os objetos vitais em um banco relacional são entidades, chaves e
relacionamentos. Entidades que representam conceitos do mundo real
que pode ser claramente identificados, tais como casas, objetos, eventos
e pessoas. Atributos identificam ou descrevem uma entidade.

21
Índice:

O índice serve para prover um acesso mais rápido a linhas das tabelas.
O funcionamento de um índice é muito simples. É mais ou menos como
um índice ao final de um livro, os principais assuntos estão no índice em
ordem alfabética. Localiza-se ali o assunto, verifica-se o número da página
em que é tratado e vai diretamente a essa página, sem precisar buscá-lo
sequencialmente nas páginas. Isso também acontece com o índice de uma
tabela.

Os valores indexados são armazenados em um objeto do banco de dados


em ordem, o que permite ao gerenciador do banco de dados pesquisar
primeiro no índice, para depois buscar na tabela.

22
Chave Candidata:
Como normalmente uma entidade apresenta mais de um atributo, existe a
possibilidade de que alguns deles preencham os requisitos indispensáveis
para se tornarem a chave primária da entidade.

Chave Primária (Primary Key):


É um atributo, ou um conjunto de atributos, que identificam uma única
ocorrência de um registro em uma entidade, de tal maneira, que não
existam dois registros na tabela com o mesmo valor de chave
primária. Os campos que a compõem são de preenchimento obrigatório.

23
Características da chave primária:

· Toda tabela deve possuir uma chave primária.


· Deve armazenar um valor único para cada registro.
· Pode ser simples ou composta.
· É de preenchimento obrigatório.
· Deve ter um valor estável, que não se altere ao longo do tempo.
· Menor extensão possível.
· De preferência campos numéricos inteiros.

24
Chave Composta:
Se um atributo, isoladamente, não consegue individualizar uma ocorrência,
um conjunto de atributos deve ser utilizado com esta finalidade.

Chave Estrangeira (Foreign Key):


É a chave primária herdada de uma entidade.

25
A seguir um resumo sobre os objetos de um banco de dados:

Tabelas -> uma tabela consiste de linhas e colunas. E usada para


armazenar dados em banco de dados relacional. Cada tabela armazena
informações sobre os tipos de objetos modelados pelo banco de dados.

26
Views -> Uma View ajuda a encapsular uma consulta em uma entidade
relacional e facilita a visão de um dado de uma ou mais tabelas em um
banco de dados.

Índices -> Num banco de dados relacional um índice oferece rápido


acesso ao dado de uma tabela baseado no valor de chave. Índices
também podem reforçar a unicidade nas linhas de uma tabela.
A chave primaria de uma tabela e automaticamente indexada. Na
pesquisa de um texto completo, um índice de texto completo armazena
informação sobre palavras significantes e a locação delas em uma dada
coluna.

27
Funções -> Uma função e um pedaço de código que opera como uma
única unidade lógica. Uma função pode retornar tanto uma tabela quanto
um valor escalar. Qualquer código que deve executar a lógica
incorporada em uma função pode chamar a função, em vez de repetir a
função lógica.

Procedimentos (Procedures) -> Um procedimento e uma coleção de


padrões T-SQL pre-compilados que são executados e retornam os
parâmetros do usuário. Você pode usar uma procedure temporária ou
permanente.

28
Gatilho (Trigger) -> Um gatilho e uma stored procedure (procedimento
armazenado) que e executada quando um dado em uma tabela especifica
e modificado. Você pode criar triggers para impor integridade referencial
entre os dados relacionados logicamente em diferentes tabelas.

Referential integrity: também conhecido como "integridade referencial",


esse recurso consiste em restrições ou regras existentes para uma correta
inserção de dados, por exemplo, para impedir que uma tabela seja
preenchida sem que isso ocorra em outra.

Schemas: recurso que permite cruzar informações em um mesmo banco


de dados, mas em estruturas diferentes.

29
1979 – A Relational Software (Oracle) concebe o SQL, em seguida ANSI
(America National Standards Institute) e ISO (International Standards
Organization) iniciam o processo de padronização da linguagem.

1986 – Surge a primeira versão padronizada pela ANSI o SQL-86.

1987 – ISO adota o mesmo padrão da ANSI.

1989 – SQL-89, segunda versão do padrão.

1992 – A terceira versão do padrão, SQL-92, é a mais utilizada atualmente.

1999 – Padrão mais recente, o SQL3, é objeto-relacional exigindo maior


complexidade de implementação.

30
SQL

Criada em meados dos anos 70, firmou-se como a linguagem padrão para
os bancos de dados relacionais por ser de fácil utilização, não requerendo
profundos conhecimentos técnicos de seus usuários.
É constituída de um conjunto de instruções que possuem a capacidade de
manipular dados, definirem estruturas de dados e especificar restrições de
segurança e integridade.
Não é uma linguagem autônoma, é uma “sublinguagem” que depende de
outras para desenvolvimento de aplicações.

31
COMPONENTES DA SQL

DDL (Data Definition Language) – Linguagem de Definição de Dados


É o conjunto de declarações que fornecem meios para a definição e
modificação das estruturas do banco de dados. Exemplos:
Comando CREATE TRIGGER
ALTER DATABASE CREATE VIEW
ALTER FUNCTION DROP DATABASE
ALTER PROCEDURE DROP FUNCTION
ALTER TABLE DROP INDEX
ALTER VIEW DROP PROCEDURE
CREATE DATABASE DROP TABLE
CREATE FUNCTION DROP TRIGGER
CREATE INDEX DROP VIEW
CREATE PROCEDURE RENAME TABLE
CREATE TABLE

32
DML (Data Manipulation Language) – Linguagem de Manipulação de
Dados
A DML permite que os acessos e as manipulações sejam realizados de
forma mais simples dentro do modelo de dados utilizado. Exemplos:

INSERT
UPDATE
DELETE

DQL (Data Query Language) – Linguagem de Consulta de Dados


Permite extrair dados do banco de dados

SELECT

33
DCL (Data Control Language) – Linguagem de Controle de Dados
Refere-se ao conjunto de instruções que permitem a implementação de
determinados níveis de acesso e privilégios, garantindo a segurança do
banco de dados. Exemplos:

GRANT
REVOKE

34
Em 1988 a Microsoft lançou sua primeira versão do SQL Server.
Ela foi desenvolvida para a plataforma OS/2 juntamente com a Microsoft e
a Sybase.
Durante os anos 90 a Microsoft iniciou o desenvolvimento de uma versão
para a plataforma NT. Enquanto o SQL Server estava sendo desenvolvido
a Microsoft decidiu que ele deveria ser uma camada encapsulada sobre o
sistema operacional NT.

35
Em 1992 a Microsoft assumiu a responsabilidade maior sobre o futuro do
SQL Server para o NT.
Em 1993 o Windows NT 3.1 e o SQL Server 4.2 para NT foram lançados. A
filosofia da Microsoft em combinar um banco de alta performance com uma
interface fácil de usar mostrou-se um sucesso. Microsoft rapidamente
tornou-se o segundo mais popular vendedor de softwares de bancos de
dados relacionais.

36
Em 1994 a Microsoft e a Sybase formalmente encerraram sua parceria.
Em 1995 a Microsoft lançou a versão 6.0 do SQL Server. Esse lançamento
foi uma das maiores rescritas da tecnologia SQL Server. A versão 6.0
aumentou a performance substancialmente provendo mecanismos internos
de replicação e administração centralizada.

37
Em 1996 a Microsoft lançou a versão 6.5 do SQL Server. Essa versão
trouxe melhoras significativas para a tecnologia e disponibilizou diversas
novas funcionalidades.
Em 1997 a Microsoft lançou a versão Enterprise do SQL 6.5.
Em 1998 a Microsoft lançou a versão 7 do SQL Server o qual foi
completamente rescrito.

38
Em 2000 a Microsoft lançou o SQL Server 2000. O SQL Server 2000 é o
lançamento mais importante do SQL Server até o momento. Essa versão
foi construída sobre o framework do SQL Server 7.0. De acordo com o time
de desenvolvimento do SQL Server essas mudanças foram desenvolvidas
para tornar essa tecnologia mais nova pelos próximos 10 anos.
2003 - O SQL Server 2000 ganha a sua versão em 64-bit podendo
acessar maiores quantidades de memória. Infelizmente o time teve de
escolher e optou por lançar o SQL Server 2000 apenas para o Itanium.

39
2005 - É lançado o SQL Server 2005 (com o codinome Yukon) com grande
integração a plataforma .NET. O SQL Server dá mais um passo em direção
às grandes plataformas corporativas. A Microsoft exibe alguns grandes
casos de sucesso (como a Xerox que consegue realizar até 7.000.000 de
transações diárias utilizando o SQL Server 2005 e a Bovespa que é a
bolsa de valores do Brasil).
2007 - A Microsoft divulga em uma feira mundial de Business Intelligence o
lançamento do SQL Server 2008 previsto para

40
2008. O principal slogan é "ir um pouco além do relacional". Novas
funcionalidades como tipos de dados geográficos, controle de carga por
usuário, etc estão previstas...

41
PostgreSQL é um sistema gerenciador de banco de dados objeto
relacional (SGBDOR), desenvolvido como projeto de código aberto.

42
Características

Hoje, o PostgreSQL é um dos SGBDs (Sistema Gerenciador de Bancos de


Dados) de código aberto mais avançados, contando com recursos como:
• Consultas complexas
• Chaves estrangeiras
• Integridade transacional
• Controle de concorrência multi-versão
• Suporte ao modelo híbrido objeto-relacional

43
• Gatilhos
• Visões
• Linguagem Procedural em várias linguagens (PL/pgSQL, PL/Python,
PL/Java, PL/Perl) para Procedimentos armazenados
• Indexação por texto
• Estrutura para guardar dados Georeferenciados PostGIS

44
O PostgreSQL é um dos resultados de uma ampla evolução que se
iniciou com o projeto Ingres, desenvolvido na Universidade de Berkeley,
Califórnia. O líder do projeto, Michael Stonebraker, um dos pioneiros dos
bancos de dados relacionais, deixou a universidade em 1982 para
comercializar o Ingres, porém retornou a ela logo em seguida. Após seu
retorno a Berkeley, em 1985, Stonebraker começou um projeto pós-
Ingres com o objetivo de resolver problemas com o modelo de banco de
dados relacional. O principal problema era a incapacidade do modelo
relacional compreender “tipos” (atualmente, chamados de objetos), ou
seja, combinações de dados simples que formam uma única unidade.

45
O projeto resultante, chamado Postgres, era orientado a introduzir a
menor quantidade possível de funcionalidades para completar o suporte a
tipos. Estas funcionalidades incluíam a habilidade de definir tipos, mas
também a habilidade de descrever relações - as quais até este momento
eram amplamente utilizadas, mas completamente mantidas pelo usuário.
No Postgres, o banco de dados "compreendia" as relações e podia obter
informações de tabelas relacionadas utilizando regras.

46
A Oracle foi fundada em agosto de 1977, inicialmente foi chamada de
Software Development Labs (SDL), uma empresa de consultoria que
contava com Bob Miner (presidente), Ed Oates e Bruce Scott (engenheiros
de software) no seu primeiro projeto. Larry Ellison, um dos grandes nomes
da Oracle, trabalhava na empresa para a qual a SDL prestava a
consultoria. Este Bruce Scott, é o Scott de ‘scott/tiger’ (Tiger era o nome
do gato da sua filha), usado até hoje nos schemas de exemplo do sistema
gerenciador de banco de dados (RDBMS) desenvolvido pela empresa.

47
Antes de formar a Oracle, Bob Miner foi gerente de Larry Ellison em um
projeto da CIA, apelidado de “Oracle”. Ed Oates e Bruce Scott fizeram
90% do trabalho de dois anos (desse projeto de consultoria), no primeiro
ano, de modo que tiveram o ano seguinte para trabalhar no Oracle. Ed
Oates terminou os outros 10% no ano seguinte, enquanto Bob e Scott
começaram a escrever o banco de dados Oracle. Quando concluíram o
trabalho decidiram entăo, que queriam ser uma empresa de produto, em
vez de uma empresa de consultoria. Mas Larry năo estava interessado
nisso. Ele estava acompanhando o que a IBM estava fazendo e descobriu
um trabalho sobre o System/R baseado no trabalho de 1970 de Codd
sobre bancos de dados relacionais.

48
Ele descrevia a linguagem SQL, que na época era chamada SEQUEL/2.
Larry levou o trabalho a Bob e Scott e perguntou se eles poderiam montar
isso. Acharam que seria muito fácil e assim começaram. Scott tinha 24
anos na época, Bob era 15 anos mais velho e Larry era 10 anos mais
velho que Sccott. Scott deixou a Oracle em 1982, depois de
aproximadamente cinco anos e meio trabalhando lá. Quando saiu, eles
tinham terminado a versăo 3 do banco de dados. Cerca de metade do
código era dele e metade de Bob. Parte do código do analisador no banco
de dados atual ainda pode ser de Scott. Bruce Scott falou de um dia que
marcou a sua vida: a conferęncia dos primeiros usuários do Oracle. Essa
foi uma conferęncia de clientes que organizaram. Aconteceu em 1982, e
reuniu entre de 25 e 50 pessoas. Foi assim que isso começou a pegar.
Fabricante: Oracle Corporation

49
Linha do tempo do RDBMS Oracle
1977 – Larry Ellison, Bob Miner, Ed Oates e Bruce Scott formam a SDL.
Larry e Bob foram parceiros em um projeto da CIA apelidado de “Oracle”.
Bob e Bruce começam a trabalhar no banco de dados. 1978 – A CIA é o
primeiro cliente, embora o produto ainda năo tenha sido lançado
comercialmente. A SDL muda seu nome para Relational Software Inc.
(RSI).
1979 – A RSI lança sua primeira versăo comercial, a versăo 2 do banco
de dados escrito em linguagem Assembler. Năo foi lançada uma versăo
1 por medo de as pessoas năo comprarem uma primeira versăo de
software. A primeira versăo comercial do software é vendida ŕ Base da
Força Aérea americana. Esse é o primeiro RDBMS comercial no
mercado.

50
1981 – A primeira ferramenta, Interactive Application Facility (IAF), que é
um predecessor da futura ferramenta SQL*Forms do Oracle, é criada.
1982 – A RSI muda seu nome para Oracle Systems Corporation (OSC) e
depois simplifica o nome para Oracle Corporation.
1983 – A versăo 3, escrita em linguagem C (que a torna portável) é
lançada. Bob Miner escreve a metade, enquanto também dá suporte ŕ V2
baseada em Assembler, e Bruce Scott escreve a outra metade. É o
primeiro RDBMS de 32 bits.
1984 – A versăo 4 é lançada. Primeiro banco de dados com coeręncia de
leitura. Oracle portado para o Personal Computer (PC).
1985 – Versőes 5 e 5.1 săo lançadas, primeiro banco de dados de servidor
paralelo no VMS/VAX.

51
1986 – O Oracle Client/Server é introduzido; primeiro banco de dados
cliente/servidor.
1987 – Oracle é a maior empresa de DBMS. Iniciado o grupo Oracle
Applications. Primeiro banco de dados SMP (multiprocessamento
simétrico) introduzido. Implementada a primeira aplicaçăo cliente/servidor
em produçăo executando o Oracle.
1988 – Lançado o Oracle V6. Primeiro bloqueio em nível de linha. Primeiro
backup de banco de dados a quente (on-line). Introduçăo da linguagem
procedural de consulta da Oracle - PL/SQL.
1992 – Lançado o Oracle V7.
1993 – Introduzidas ferramentas GUI de desenvolvimento cliente/servidor
do Oracle. Oracle Applications passou para cliente/servidor.

52
1994 – Bob Miner morre de câncer.
1995 – Primeiro banco de dados de 64 bits.
1996 – Lançado o Oracle7.3.
1997 – O Oracle 8 é apresentado. O Oracle Application Server é
apresentado, assim como aplicaçőes para a Web. Oracle é o primeiro
banco de dados para Web. Ferramentas Oracle BI, como Discoverer, săo
introduzidas para data warehousing. Ferramentas possuem suporte nativo
para Java.

53
1998 – Primeiro grande RDBMS (Oracle 8) portado para o Linux. Oracle é
o primeiro banco de dados com suporte para Java.
1999 – Lançado o Oracle 8i. Integra Java/XML nas ferramentas de
desenvolvimento. Oracle é o primeiro banco de dados com suporte nativo
para XML.
2000 – Lançado o Oracle9i Application Server, tornando-se o primeiro
banco de dados com cache na camada intermediária. Lançado o E-
Business Suite, banco de dados sem fio com OracleMobile, Oracle9i
Application Server Wireless e Internet File System (IFS).

54
2001 – Lançado o Oracle9i (9.1). Oracle é o primeiro banco de dados com
Real Application Clusters (RAC).
2002 – Lançado o Oracle9i Release 2 (9.2).
2003 – Lançado o Oracle 10g – banco de preparado para o Grid
Computing.
2007 – Previsăo de lançamento do Oracle 11g.

55
A Sybase, uma empresa do SAP, cria a tecnologia que proporciona a
empresa sem fio para os clientes e parceiros através do fornecimento de
infraestrutura corporativa e móvel e soluções de software de
desenvolvimento e integração. Os dados mais importantes do mundo nas
áreas de comércio, finanças, governo, saúde e defesa são executados nos
produtos Sybase. Veja a seguir uma breve cronologia das principais
conquistas no decorrer de duas décadas como empresa líder em
tecnologia.

56
1984 A Sybase foi fundada por Mark Hoffman e Bob Epstein na residência
do Sr. Epstein, em Berkeley, Califórnia.
1988 A Sybase é a primeira no mercado a disponibilizar um banco de
dados relacional cliente/servidor, fornecendo ao Projeto Genoma Humano
(Human Genome Project) as licenças para a primeira geração de bancos
de dados relacionais cliente/servidor.
1990 A Sybase é a primeira a oferecer a tecnologia aberta de replicação.

57
1994 A Sybase é considerada líder em tecnologia aberta de middleware.
1995 A Sybase é líder em ferramentas de desenvolvimento
cliente/servidor com o PowerBuilder.
1998 A Sybase iAnywhere distribui mais de 5 milhões de licenças do SQL
Anywhere.
1999 A Sybase é líder de mercado em mercados de capitais, oferecendo
uma suíte de aplicativos destinados a serviços bancários e de corretagem
on-line.

58
Maio de 2000

A iAnywhere Solutions é estabelecida como subsidiária da Sybase.


Nov A Sybase é a primeira a oferecer um servidor de aplicativo J2EE.
2001 A Sybase iAnywhere é a líder do mercado de banco de dados
móvel pelo quinto ano consecutivo.
Maio de 2002

A Sybase iAnywhere conquista o prêmio Mobility Award for Best


Database. Julho A Financial Fusion Inc. é classificada pela Celent
Communications como a número um em solução de operações
bancárias pela Internet pelo segundo ano consecutivo.
Julho A Sybase supera todos os outros servidores de aplicativos com
resultados recorde no benchmark independente da ECperf.

59
O MySQL foi criado na Suécia por dois suecos e um finlandês: David
Axmark, Allan Larsson e Michael "Monty" Widenius, que têm trabalhado
juntos desde a década de 1980. Hoje seu desenvolvimento e manutenção
empregam aproximadamente 400 profissionais no mundo inteiro, e mais de
mil contribuem testando o software, integrando-o a outros produtos, e
escrevendo a respeito dele.

60
No dia 16 de Janeiro de 2008, a MySQL AB, desenvolvedora do MySQL foi
adquirida pela Sun Microsystems, por US$ 1 bilhão, um preço jamais visto
no setor de licenças livres. No dia 20 de Abril de 2009 a Oracle compra a
Sun Microsystems e todos o seus produtos, incluindo o MySQL. Após
investigações da Comissão Europeia sobre a aquisição para evitar
formação de monopólios no mercado a compra foi autorizada e hoje a Sun
faz parte da Oracle.

61
Características

• Portabilidade (suporta praticamente qualquer plataforma atual);


• Compatibilidade (existem drivers ODBC, JDBC e .NET e módulos de
interface para diversas linguagens de programação, como Delphi, Java,
C/C++, C#, Visual Basic, Python, Perl, PHP, ASP e Ruby)
• Excelente desempenho e estabilidade;
• Pouco exigente quanto a recursos de hardware;
• Facilidade de uso;
• É um Software Livre com base na GPL;

62
• Contempla a utilização de vários Storage Engines como MyISAM,
InnoDB, Falcon, BDB, Archive, Federated, CSV, Solid…
• Suporta controle transacional;
• Suporta Triggers;
• Suporta Cursors (Non-Scrollable e Non-Updatable);
• Suporta Stored Procedures e Functions;
• Replicação facilmente configurável;
• Interfaces gráficas (MySQL Toolkit) de fácil utilização cedidos pela
MySQL Inc.

63
SISTEMA DE GERENCIAMENTO
DE BANCO DE DADOS
RELACIONAL
Charles Emerson Machado

Charles.emerson.machado@gmail.com

64
Falhas no entendimento de um sistema ocorrem devido a falhas
nos seus eventos.
– A história do desenvolvimento de um sistema de balanço.

Falha no entendimento do sistema devido a uma provável falta


de feedback
65
Estrutura
de dados

Programa
funcionando

Plano Especificação Projeto Listagem


de requisitos

Especificação
de testes

66
Modelos de Dados

Um modelo de Dados é um conjunto de conceitos formais utilizados para


a definição de BD (descrição do dados, das relações entre eles, da
semântica de dados e das restrições entre eles).
A característica básica de um modelo de dados, como o próprio termo
explicita, é que ele corresponde a uma abstração da realidade. A distância
existente entre a maneira na qual as entidades existem na realidade e a
maneira como estas entidades são representadas internamente nos
computadores levaram ao surgimento de modelos de dados em diferentes
níveis de abstração.
A Modelagem de dados é o processo de abstração onde somente os
elementos essenciais da realidade são enfatizados para a aplicação em
questão, descartando-se os elementos não essenciais. O principal
objetivo da modelagem de dados é transmitir e apresentar uma
representação única, não redundante e resumida dos dados de uma
determinada aplicação.

67
Os modelos de dados são classificados em conceituais,
lógicos e físicos de acordo com os conceitos que utilizam para
representar os dados.

Modelos Conceituais

O objetivo da modelagem conceitual é descrever as informações contidas


em uma realidade, as quais estarão armazenadas em um BD. É uma
descrição alto nível, mas que tem a preocupação de captar e retratar toda
a realidade de uma organização.
São modelos mais abstratos que utilizam conceitos como objetos,
propriedades dos objetos e a relação entre eles para representar os
dados, estruturados independentemente das restrições de
implementação. O modelo mais utilizado na modelagem conceitual é o
Modelo Entidade-Relacionamento.

68
MODELO ENTIDADE RELACIONAMENTO

Relacionamento

"Um modelo conceitual ( o Modelo Entidade Relacionamento é um tipo) é;


um modelo (lógico) detalhado que captura a estrutura dos dados
organizacional enquanto sendo independente de qualquer sistema de
gerenciamento de base de dados ... "
McFadden & Hoffer, p. 87

69
Diagrama Entidade-Relacionamento
A estrutura lógica geral de um banco de dados pode ser expressa
graficamente por um Diagrama Entidade-Relacionamento.

Componentes do Diagrama E-R (Peter Chen):

- Retângulos: representam conjuntos-entidade


- Elipses: representam atributos
- Losangos: representam conjuntos-relacionamento
- Linhas: ligam atributos a conjuntos-entidade e conjuntos-entidade a
conjuntos-relacionamento

70
Entidades e Conjuntos-Entidade

Entidade: é uma representação abstrata de um objeto do mundo real


Ex.: O fornecedor Pedro, com código F1

Conjuntos-Entidade: grupo de entidades que possui características


semelhantes
Ex.: Conjunto-entidade Fornecedor

71
Atributos (campos)

Atributo: Elemento de dado que contém informação que descreve uma


entidade
Ex.:

Atributo Monovalorado: assume um único valor para cada elemento do


conjunto-entidade
Ex.: Nome
Atributo Composto: formado por um ou mais sub-atributos
Ex.: Endereço

72
Atributo Multivalorado: uma única entidade tem diversos valores para
este atributo (seu nome é sempre representado no plural)
Ex.: Dependentes

Atributo Determinante: identifica cada entidade de um conjunto-entidade


(também conhecido com atributo chave)
Ex.: Cod_Func

Domínio de um Atributo: conjunto de valores permitidos para o atributo


Ex.: Sexo {M, F}

73
Relacionamentos

Relacionamento: estrutura que indica a associação de elementos de


duas ou mais entidades.

Atributo de Relacionamento: depende de todos os conjuntos-entidade


associados entre si.

74
Modelo Conceitual

75
Modelos Lógicos

Têm seu início a partir do modelo conceitual. Descreve as estrutura que


estarão contidas no BD, mas sem considerar, ainda, nenhuma
característica específica de um SGBD, resultando em um esquema lógico
de dados sob uma das seguintes abordagens: modelo relacional, modelo
de redes e modelo hierárquico. São modelos mais próximos da
implementação e utilizam conceitos como registros para representar os
dados.

76
Modelo Lógico

77
Modelos Físicos

Parte do modelo lógico e descreve as estruturas físicas de


armazenamento de dados, tais como, tamanho dos campos, índices,
formas de acesso, etc. Descrevem como os dados são armazenados
fisicamente.

78
/*==============================================================
*/
/* DBMS name: MySQL 5.0 */
/* Created on: 19/9/2011 00:49:19 */
/*==============================================================
*/

drop table if exists BAIRRO;

drop table if exists FUNCIONARIO;

drop table if exists PESSOA;

79
/*=======================================================*/
/* Table: BAIRRO */
/*=======================================================*/
create table BAIRRO
(
BAI_CODIGO int not null,
BAI_NOME varchar(20) not null,
primary key (BAI_CODIGO)
);

80
/*===============================================*/
/* Table: FUNCIONARIO */
/*===============================================*/
create table FUNCIONARIO
(
FUN_CODIGO int not null,
BAI_CODIGO int not null,
FUN_NUMERO varchar(10),
FUN_COMPLEMENTO varchar(10),
FUN_CEP char(9),
FUN_CPF char(11),
FUN_RG varchar(18),
primary key (FUN_CODIGO)
);

81
/*======================================================*/
/* Table: PESSOA */
/*======================================================*/
create table PESSOA
(
PES_CODIGO int not null,
BAI_CODIGO int not null,
PES_NUMERO varchar(10),
PES_COMPLEMENTO varchar(10),
PES_CEP char(9),
PES_CPF char(11),
PES_RG varchar(18),
PES_FONERES char(16),
primary key (PES_CODIGO)
);

82
alter table FUNCIONARIO add constraint
FK_BAIRRO_DO_FUNCIONARIO foreign key (BAI_CODIGO)
references BAIRRO (BAI_CODIGO) on delete restrict on update
restrict;

alter table PESSOA add constraint FK_BAIRRO_DA_PESSOA foreign


key (BAI_CODIGO)
references BAIRRO (BAI_CODIGO) on delete restrict on update
restrict;

83
Exercício - Modelagem

Construa o modelo Entidades-Relacionamentos a partir da seguinte


descrição do sistema:

Pretende-se criar uma base de dados que permita gerir uma parte da
informação de uma clinica de saúde.
Fundamentalmente a base de dados deverá guardar a informação
relativa aos doentes que frequentam a clínica (nome, morada, telefone
e numero de beneficiário) e dos médicos que lá trabalham (nome,
morada, contacto e especialidade).
Para além disso o sistema deverá registar as marcações de consultas
de cada paciente para um determinado médico sabendo que esse
médico só pratica uma determinada especialidade.

84
MySQL Query Browser

O MySQL Query Browser é uma ferramenta gráfica fornecida pela


MySQL AB para criar, executar e otimizar solicitações SQL em um
ambiente gráfico. Assim como o MySQL Administrator foi criado para
administrar um servidor MySQL, o MySQL Query Browser foi criado
para auxiliar você a selecionar e analisar dados armazenados dentro de
um Banco de Dados MySQL.
Enquanto todas as solicitações executadas no MySQL Query Browser
também podem ser executadas pela linha de comando utilizando-se o
utilitário mysql, o MySQL Query Browser permite a execução e edição
dos dados de maneira gráfica, que é mais intuitiva para o usuário.

85
86
Procedimentos

Instalar um pacote como o XAMPP ou qualquer outro que habilite o


MYSQL.
O próprio site da MYSQL disponibiliza o banco.
O pacote MYSQL TOOLS, dispõem da tradução para nosso idioma do:
• MYSQL ADMINISTRATOR
• MYSQL QUERY BROWSER
• MYSQL MIGRATION TOOLKIT
O aplicativo WORKBENCH 5.2 CE, possui funções para modelar dados
e um editor de script em SQL.

87
Os arquivos que compõem o banco de dados ficam
armazenados na sub pasta DATA.

88
Lista de arquivos criados para um banco de dados para a
ENGENHARIA DE ARMAZENAMENTO MYISAM.

O índice é armazenado em um arquivo com extensão .MYI (MYIndex).


Os dados são armazenados em um arquivo com a extensão .MYD
(MYData).

O MySQL armazena suas informações de dicionários de dados de tabelas


em arquivos .frm no diretório de banco de dados. Mas todo tabela do tipo
InnoDB também tem sua própria entrada no dicionários de dados interno
do InnoDB dentro da tablespace. Quando o MySQL apaga uma tabela ou
um banco de dados, ele tem que deletar o(s) arquivo(s) .frm e a entrada
correspondente dentro do dicionário de dados do InnoDB. Esta é a razão
pela qual você não pode mover tabelas InnoDB entre banco de dados
simplesmente movendo os arquivos .frm e porque DROP DATABASE não
funcionava em tabelas do tipo InnoDB em versÕes do MySQL anteriores a
3.23.43.

89
TIPO DE DADOS

O MySQL permite o armazenamento em diversos tipos de dados.


É importante conhece-los para conseguirmos criar nossas tabelas de
forma correta e otimizada para o tipo de dados que ela armazenará.

Podemos agrupar o tipos da seguinte forma:


● Numéricos
● Strings (textos)
● Temporais

90
Espaço de armazenamento

O que é esse espaço de armazenamento?


Espaço em disco que cada valor de um determinado tipo irá ocupar.

● O somatório de bytes de todas as colunas de um registro (tupla ou linha) pode


nos auxiliar na projeção de crescimento do nosso banco.

Ex: Usar tipo INT para campo de usuário ativo ( 1 – ativo , 0 – inativo) -
Desperdício de espaço.

91
O TIPO NUMÉRICO

Pode ser utilizado no tratamento de valores numéricos inteiros


ou reais. Estão disponíveis os seguintes tipos:

SMALLINT – [(tamanho)] – Utiliza-se este tipo de dado quando houver a


necessidade de fazer uso de valores inteiros curtos entre a faixa de
valores de –32.768 até 32.767. O parâmetro tamanho é opcional e
permite estabelecer o tamanho máximo do valor a ser exibido, podendo
ser um valor máximo 255;

INTEGER [(tamanho)] – Utiliza-se este tipo de dado quando houver a


necessidade de fazer uso de valores inteiros longos entre a faixa de
valores de –2.147.483.648 até 2.147.483.647. O parâmetro tamanho é
opcional e permite estabelecer o tamanho máximo do valor a ser exibido,
podendo ser um valor máximo 255;

92
DECIMAL[(tamanho[,decimal])] – Utiliza-se este tipo de dado quando houver a
necessidade de fazer uso de valores com ponto flutuante. O parâmetro tamanho
é opcional e permite estabelecer o tamanho máximo do valor a ser exibido,
podendo ser um valor máximo 255. Se omitido, o tamanho assumido é 10. O
parâmetro opcional decimal permite estabelecer o tamanho máximo de casas
decimais a ser exibido, podendo, ser um valor máximo de 30;

NUMERIC[(tamanho[,decimal])] – Utiliza-se este tipo de dado quando houver a


necessidade de fazer uso de valores com ponto flutuante, sendo semelhante ao
tipo DECIMAL;

DOUBLE PRECISION[(tamanho.decimal)] – Utiliza-se este tipo de dado quando


houver a necessidade de fazer uso de valores com ponto de dupla precisão. O
parâmetro tamanho deve estar entre 25 e 53 para estabelecer o tamanho
máximo. O parâmetro opcional decima permite estabelecer o tamanho máximo
de casas decimais a ser exibido, podendo ser um valor máximo de 30.

93
FLOAT – Utiliza-se este tipo de dado quando houver a necessidade de fazer uso
de valores com ponto flutuante com sete dígitos de precisão decimais. Este tipo
permite trabalhar com valores na faixa de 3,4 * 10-38 até 3,4 * 1038 ;

94
O TIPO TEMPORAL

Pode ser utilizado no tratamento de valores relacionados ‘a data e horário.


Estão disponíveis os seguintes tipos:

DATE – Utiliza-se este tipo de dado quando houver a necessidade de


fazer uso de uma data de calendário no formato AAAA-MM-DD (formato
ANSI). O intervalo aceito depende da ferramenta de gerenciamento de
banco de dados em uso.

TIME – Utiliza-se este tipo de dado quando houver a necessidade de


fazer uso de uma informação relacionada a um determinado horário.

95
DATE:
Uma data. A faixa suportada é entre '1000-01-01' e '9999-12-31'.
Formato 'AAAA-MM-DD‘

TIME:
Uma hora. A faixa é entre '-838:59:59' e '838:59:59'. Formato 'HH:MM:SS‘

DATETIME:
Um combinação de hora e data. A faixa suportada é entre '1000-01-01
00:00:00' e '9999-12-31 23:59:59'.

YEAR[(2|4)]:
Um ano no formato de 2 ou 4 digitos (padrão são 4 digitos)

96
TIMESTAMP:
Similiar ao datetime com algumas particularidades.
Formato: 'AAAA-MM-DD HH:MM:SS'.

Padrão é NOT NULL.


No insert e update ele é atualizado automaticamente.

97
O TIPO LITERAL

O Tipo Literal pode ser para a recepção de valores baseados em


cadeias de caracteres(strings – dados alfanuméricos delimitados por
aspas ou apóstrofos). Estão disponíveis os seguintes tipos:

CHAR(tamanho) – Utiliza-se este tipo de dado quando houver a


necessidade de fazer uso de seqüências de caracteres de tamanho fixo
que estejam limitadas até 255 caracteres de comprimento. O parâmetro
tamanho determina o valor máximo em caracteres que pode conter a
seqüência;

98
VARCHAR(tamanho) – Utiliza-se este tipo de dado quando houver a
necessidade de fazer uso de seqüências de caracteres de tamanho variável que
estejam limitadas até 255 caracteres de comprimento. A diferença entre este tipo
e o CHAR é que neste caso, os espaços em branco excedentes do lado direito da
seqüência de caracteres não utilizados são automaticamente desprezados. O
parâmetro tamanho determina o valor máximo em caracteres que pode conter a
seqüência .

99
SISTEMA DE GERENCIAMENTO
DE BANCO DE DADOS
RELACIONAL
Charles Emerson Machado

Charles.emerson.machado@gmail.com

100
ESTRUTURAS DE ARQUIVOS

ARQUIVO SEQÜENCIAL

Nos arquivos seqüenciais a ordem lógica e física dos registros armazenados é a


mesma. Os registros podem estar dispostos seguindo a seqüência determinada
por uma chave primária (chamada chave de ordenação), ou podem estar
dispostos aleatoriamente.
# Numero Nome Idade Salario
0 1000 ADEMAR 25 600
1 1050 AFONSO 27 700
2 1075 CARLOS 28 500
3 1100 CESAR 30 1000
4 1150 DARCI 23 1500
5 1180 EBER 22 2000
6 1250 ENIO 27 750
7 1270 FLAVIO 28 600
8 1300 IVAN 30 700
9 1325 MIGUEL 34 1000
10 1340 MARIA 35 1500
11 1360 RAMON 32 2000
12 1400 SANDRA 29 700
13 1450 TATIANA 30 500
101
INSERÇÃO DE UM REGISTRO

Se o arquivo não está ordenado, o registro pode ser simplesmente


inserido após o último registro armazenado.
Se o arquivo está ordenado, normalmente é adotado o seguinte
procedimento:
Dado um arquivo base B, é construído um arquivo de transações T, que
contem os registros a serem inseridos, ordenado pela mesma chave
que o arquivo B. Os arquivos B e T são então intercalados, gerando o
arquivo A, que é a versão atualizada de B.

102
Arquivo B Arquivo T Arquivo A
# Num Nome Idade # Num Nome Idade # Num Nome Idade
0 1000 ADEMAR 25 0 1070 ANGELA 25 0 1000 ADEMAR 25
1 1050 AFONSO 27 1 1120 CLAUDIA 27 1 1050 AFONSO 27
2 1075 CARLOS 28 2 1280 IARA 28 2 1070 ANGELA 25
3 1100 CESAR 30 3 1310 LUIS 30 3 1075 CARLOS 28
4 1150 DARCI 23 4 1420 SONIA 23 4 1100 CESAR 30
5 1180 EBER 22 5 1120 CLAUDIA 27
6 1250 ENIO 27 6 1150 DARCI 23
7 1270 FLAVIO 28 7 1180 EBER 22
8 1300 IVAN 30 8 1250 ENIO 27
9 1325 MIGUEL 34 9 1270 FLAVIO 28
10 1340 MARIA 35 10 1280 IARA 28
11 1360 RAMON 32 11 1300 IVAN 30
12 1400 SANDRA 29 12 1310 LUIS 30
13 1450 TATIANA 30 13 1325 MIGUEL 34
14 1340 MARIA 35
15 1360 RAMON 32
16 1400 SANDRA 29
17 1420 SONIA 23
18 1450 TATIANA 30

103
ARQUIVO INDEXADO

O arquivo indexado é aquele em que os registros são acessados através


de um ou mais índices, não havendo qualquer compromisso com a
ordem em que os registros estão armazenados.
Podem existir tantos índices quantas forem as chaves de acesso aos
registros. As entradas no índice são ordenadas pelo valor das chaves de
acesso, sendo cada uma delas constituída por um par (chave do
registro, endereço do registro).

104
Índice Arquivo
Num End. # Num Nome Idade Salário
ADEMAR 1 0 2010 WILSON 26 1000
AFONSO 13 1 1000 ADEMAR 32 250
ANGELA 2 2 1070 ANGELA 28 300
CARLOS 16 3 1200 CLAUDIA 25 750
CESAR 22 4 1300 DIOGO 24 400
CLAUDIA 3 5 1400 EDISON 22 1500
CRISTIE 10 6 1510 FLAVIO 30 250
DARCI 19 7 1590 HELENA 26 300
DIOGO 4 8 1650 IVAN 32 750
ELBER 14 9 1730 MIGUEL 28 400
EDISON 5 10 1250 CRISTIE 25 1500
EDMUNDO 17 11 1520 GENARO 24 750
ENIO 23 12 1740 RAMON 22 400
FLAVIO 6 13 1050 AFONSO 30 1500
GENARO 11 14 1310 ELBER 26 250
GERSON 20 15 1605 IARA 32 300
HELENA 7 16 1075 CARLOS 28 750
IARA 15 17 1430 EDMUNDO 26 400
IVAN 8 18 1700 LUIS 32 1500
LUIS 18 19 1275 DARCI 26 750
MARIA 24 20 1530 GERSON 26 400
MIGUEL 9 21 1745 SANDRA 32 400
RAMON 12 22 1100 CESAR 28 1500
SANDRA 21 23 1470 ENIO 25 750
SONIA 25 24 1710 MARIA 24 400
TATIANA 26 25 1800 SONIA 22 750
WILSON 0 26 1905 TATIANA 30 400

105
ABSTRAÇÃO DE DADOS

Um propósito central de um SGBD é proporcionar aos usuários uma visão


abstrata dos dados, isto é, o sistema esconde certos detalhes de como os
dados são armazenados ou mantidos. No entanto, os dados precisam ser
recuperados eficientemente.
A preocupação com a eficiência leva a concepção de estruturas de dados
complexas para representação dos dados no BD. Porém, uma vez que
SGBD são freqüentemente usados por pessoas sem treinamento na área
de computação, esta complexidade precisa ser escondida dos usuários.
Isto é conseguido definindo-se diversos níveis de abstração pelos quais o
BD pode ser visto:

106
NÍVEL FÍSICO: É o nível mais baixo de abstração, no qual se descreve
como os dados são armazenados. Estruturas complexas, de baixo nível,
são descritas em detalhe.

NÍVEL CONCEITUAL: É o nível que descreve quais os dados são


realmente armazenados no BD e quais os relacionamentos existentes entre
eles. Este nível descreve o BD como um pequeno número de estruturas
relativamente simples. Muito embora a implementação de estruturas
simples no nível conceitual possa envolver estruturas complexas no nível
físico, o usuário do nível conceitual não precisa saber disto.

NÍVEL VISÃO: Este é o nível mais alto de abstração, no qual se expõe


apenas parte do BD. Na maioria das vezes os usuários não estão
preocupados com todas as informações do BD e sim com apenas parte
delas (Visões dos Usuários)

107
INDEPENDÊNCIA DE DADOS

Independência de dados a nível físico: a capacidade de se modificar o


modelo físico, sem precisar reescrever os programas de aplicação.

Independência dados a nível lógico: a capacidade de se modificar o


esquema lógico, sem a necessidade de reescrever os programas de
aplicação. Modificações no nível lógico são necessárias sempre que a
estrutura lógica do BD for alterada. Em alguns casos a recompilação pode
ser requerida.

108
FASES DO PROJETO DE BD

CONSTRUIR O MODELO CONCEITUAL

•Modelo de alto nível, independente da implementação


•Etapa de levantamento de dados
•Uso de uma técnica de modelagem de dados
•Abstração do ambiente de hardware/software

CONSTRUIR O MODELO LÓGICO

•Modelo implementável, dependente do tipo de SGBD a ser usado


•Considera as necessidades de processamento
•Considera as características e restrições do SGBD
•Etapa de normalização dos dados

109
CONSTRUIR O MODELO FÍSICO

•Modelo implementável, com métodos de acesso e estrutura física


•Considera necessidades de desempenho
•Considera as características e restrições do SGBD
•Dependente das características de hardware/software

AVALIAR O MODELO FÍSICO

•Avaliar o desempenho das aplicações


•Avaliar os caminhos de acesso aos dados e estruturas utilizadas

IMPLEMENTAR O BD

•Etapa de carga (load) dos dados


•Gerar as interfaces com outras aplicações

110
MODELAGEM DE DADOS

CONCEITOS

Abstração: processo mental através do qual selecionamos


determinadas propriedades ou características dos objetos e excluímos
outras, consideradas menos relevantes para o problema sendo
analisado.

Modelo: é uma abstração, uma representação simplificada, de uma


parcela do mundo real, composta por objetos reais.

Modelagem: atividade através da qual se cria um modelo.

Modelo de dados: Um modelo de dados é uma descrição das


informações que devem ser armazenadas em um banco de dados, ou
seja, é a descrição formal da estrutura de BD (descrição dos dados, dos
relacionamentos entre os dados, da semântica e das restrições impostas
aos dados).

111
REQUISITOS PARA MODELAGEM DE DADOS

Entender a realidade em questão, identificando os objetos que compõe a


parte da realidade que vai ser modelada..
Representar formalmente a realidade analisada, construindo um modelo
de dados.
Estruturar o modelo obtido e adequá-lo ao SGBD a ser usado,
transformando o modelo conceitual em modelo lógico.

112
SISTEMA DE GERENCIAMENTO
DE BANCO DE DADOS
RELACIONAL
Charles Emerson Machado

Charles.emerson.machado@gmail.com

113
Após conectar ao banco de dados, execute os comandos abaixo para:

SHOW DATABASES; - Listar todos os BD´s criados.

SELECT VERSION(); - Verificar a versão do MYSQL.

SELECT USER(); - Usuário conectado ao BD.

114
COMANDOS DDL

DEFINIÇÃO DE DADOS

CREATE DATABASE [IF NOT EXISTS] nome_bd

Banco de dados no MySQL são implementados como diretórios contendo


arquivos que correspondem a tabelas no banco de dados. Por não haver
tabelas em um banco de dados quando ele é criado, a instrução CREATE
DATABASE apenas cria um diretório sob o diretório de dados do MySQL.

115
NOMES DE BANCO DE DADOS, TABELA, INDICE, COLUNA E
ALIAS

Nomes de banco de dados, tabela, índice, coluna e apelidos seguem


todos as mesmas regras no MySQL.
Note que as regras foram alteradas a partir do MySQL versão 3.23.6,
quando introduzimos aspas em identificadores (nomes banco de dados,
tabela e coluna) com ‘`’. ‘"’ funcionará também para citar identificadores
se você executar no modo ANSI.

Identificador Tamanho máximo (bytes) Caracteres permitidos


Banco de dados 64 Qualquer caractere que é permitido em
um nome de diretório exceto ‘/’ ou ‘.’.
Tabela 64 Qualquer caractere permitido em um
nome de arquivo, exceto ‘/’ ou ‘.’.
Coluna 64 Todos os caracteres.
Alias 255 Todos os caracteres.

116
DROP DATABASE

DROP DATABASE [IF EXISTS] nome_bd

DROP DATABASE deleta todos as tabelas no banco de dados e deleta o


banco de dados. Se você fizer um DROP DATABASE em um banco de
dados ligado simbolicamente, o link e o banco de dados original são
deletados. Tenha cuidado com este comando!
DROP DATABASE retorna o número de arquivos que foram removidos do
diretório de banco de dados. Para tabelas MyISAM, isto é três vezes o
úmero de tabelas, pois cada tabela corresponde a um arquivo ‘.MYD’, um
arquivo ‘.MYI’ e um arquivo ‘.frm’.

117
O comando DROP DATABASE remove do diretório de banco de dados
dado todos os arquivos com a seguinte extensão:

Ext Ext Ext Ext


.BAK .DAT .HSH .ISD
.ISM .ISM .MRG .MYD
.MYI .db .frm

Todos os subdiretórios que consistem de 2 dígitos (diretórios RAID)


também são removidos.

118
CREATE TABLE

O comando CREATE TABLE permite criar e definir a estrutura de uma


tabela(arquivo) definido as colunas (campos) e as chaves primárias e
estrangeiras existentes. Sua sintaxe é:

CREATE [TEMPORARY] TABLE [IF NOT EXISTS] nome_tabela


[(definição_create,...)]
[table_options] [select_statement]

Ou

CREATE [TEMPORARY] TABLE [IF NOT EXISTS] nome_tabela [(]LIKE


nome_antigo_tabela[)];

119
Onde:
nome-tabela - Representa o nome da tabela que será criada.

Definição_create

•nome-coluna - Representa o nome da coluna que será criada. A


definição das colunas de uma tabela é feita relacionando-as uma após
a outra.

•tipo-do-dado - Define o tipo e tamanho dos campos definidos para a


tabela. Os tipos de dados

120
ALTER TABLE

ALTER TABLE lhe permite alterar a estrutura da tabela existente. Por


exemplo, você pode adicionar ou deletar colunas, criar ou remover índices,
alterar o tipo de coluna existentes, ou renomear coluna ou tabelas.

ALTER [IGNORE] TABLE nome_tbl especificação_alter

121
especificação_alter:

ADD [COLUMN]
| ADD INDEX [nome_indice] (index_nome_col,...)
| ADD [CONSTRAINT [symbol]] PRIMARY KEY (index_col_name,...)
| ADD [CONSTRAINT [symbol]] FOREIGN KEY [index_name]
(index_col_name,...)

122
[definição_referência]

| ALTER [COLUMN] nome_col {SET DEFAULT literal | DROP DEFAULT}


| MODIFY [COLUMN] definição_create [FIRST | AFTER nome_coluna]
| DROP [COLUMN] nome_col
| DROP PRIMARY KEY
| DROP INDEX nome_indice
| DISABLE KEYS
| ENABLE KEYS
| RENAME [TO] nome_nova_tbl
| ORDER BY col
| CHARACTER SET character_set_name [COLLATE collation_name]
| table_options

123
RENAME TABLE

A renomeação é feita automicamente, o que significa que nenhuma outra


thread pode acessar qualquer uma das tabelas enquanto a renomeação
está sendo executada.

RENAME TABLE tabela_antiga TO tabela_backup;

124
DROP TABLE

DROP TABLE remove uma ou mais tabelas. Todos os dados e definições


de tabela são removidos, assim tenha cuidado com este comando!

DROP TABLE [IF EXISTS] nome_tabela;

125
COMANDOS DML

INSERT

INSERT insere novos registros em uma tabela existente. A forma INSERT


... VALUES da instrução insere registros baseado em valores especificados
explicitamente.

INSERT [INTO] nome_tabela [(nome_coluna,...)] VALUES ((expressão |


DEFAULT),...)

126
nome_tabela é a tabela na qual as linhas serão inseridas. A lista
de nome das colunas ou a cláusula SET indica para quais colunas
a instrução especifica valor:

Se você não especificar a lista de colunas para INSERT ... VALUES ou


INSERT ... SELECT, os valores para todas as colunas na tabela devem ser
fornecidos na lista VALUES() ou pelo SELECT. Se você não souber a
ordem das colunas nas tabelas, use DESCRIBE nome_tabela para
descobrir.
Qualquer coluna que não tiver o valor fornecido explicitamente assumirá o
seu valor padrão. Por exemplo, se você especificar uma lista de colunas
que não definem todas as colunas na tabela, às colunas não definidas
serão atribuídos o seu valor padrão.

127
UPDATE

UPDATE atualiza uma coluna em registros de tabelas existentes com


novos valores. A cláusula SET indica quais colunas modificar e os valores
que devem ser dados. A cláusula WHERE, se dada, especifica quais
linhas devem ser atualizadas. Senão todas as linhas
são atualizadas.

UPDATE nome_tabela
SET nome_coluna1=expr1 [, nome_coluna2=expr2 ...]
[WHERE definição_where]

128
DELETE

DELETE deleta linhas de nome_tabela que satisfaçam a condição dada


por definição_where, e retorna o número de registros
deletados.

DELETE FROM table_name


[WHERE definição_where]

129
DQL

Sintaxe SELECT

SELECT é utilizado para retornar registros selecionados de uma ou mais


tabelas. Cada expressão_select indica as colunas que você deseja
recuperar. SELECT tanbém pode ser utilizado para retornar registros
calculados sem referência a nenhuma tabela.

Por exemplo:
mysql> SELECT 1 + 1;
-> 2
Uma expressão SELECT pode utilizar um alias usando AS nome_alias. O
alias é usado como o nome da coluna da expressão e pode ser usado com
cláusulas ORDER BY ou HAVING.

130
A cláusula FROM table_references indica a tabela de onde os registros
serão retornados. Se você indicar mais de uma tabela, você estará
realizando uma join.
Na cláusula WHERE, você pode usar qualquer uma das funções
suportadas pelo MySQL.
As otimizações WHERE são colocadas aqui na parte da SELECT porque
normalmente elas são usadas com SELECT, mas as mesmas otimizações
aplicam-se para WHERE em instruções DELETE e UPDATE.

A cláusula HAVING pode se referir a qualquer coluna ou alias definido na


expressão_select. Ele é aplicado no final, pouco antes dos itens serem
enviados ao cliente, sem otimização. LIMIT é aplicada depois de HAVING.)
estar na cláusula WHERE.

131
Se você utiliza GROUP BY, os registros de saída serão ordenados de
acordo com o GROUP BY como se você tivesse um ORDER BY sobre
todos os campos no GROUP BY. O MySQL tem expandido a cláusula
GROUP BY para que você também possa especificar ASC e DESC depois
das colunas chamadas na cláusula

As opções DISTINCT, DISTINCTROW e ALL especificam quando registros


duplicados devem ser retornados. O padrão é (ALL), todos os registros
coincidentes são retornados. DISTINCT e DISTINCTROW são sinônimos e
espcificam que registros duplicados no conjunto de resultados devem ser
remopvidos.

132
SELECT [DISTINCT]
expressão_select,... AS alias
[FROM tabelas_ref AS alias
[WHERE definição_where]
[GROUP BY {inteiro_sem_sinal | nome_col | formula} [ASC | DESC], ...
[HAVING where_definition]
[ORDER BY {inteiro_sem_sinal | nome_coluna | formula} [ASC | DESC], ...]

WHERE - determina quais as linhas deverão ser retornadas. A cláusula


where também é conhecida por critério.

133
OPERADORES DE COMPARAÇÃO

= Igual
> Maior
< Menor
>= Maior ou igual
<= Menor ou igual
<> ou != Diferente ou não igual
LIKE Parecido – O símbolo de % é usado para não considerar
determinadas partes da pesquisa no atributo.

134
OPERADORES AND E OR

Operador AND
E = somente retornará os dados quando as condições forem todas
satisfeitas

Operador OR
OU = retorna dados assim que qualquer das condições for satisfeita

135
OPERADORES DE AGREGAÇÃO

MIN Retorna o menor valor


MAX Retorna o maior valor
COUNT Retorna a quantidade de valores
AVG Retorna a média dos valores
SUM Retorna a soma dos valores

136
OPERADORES IN, BETWEEN, NOT IN E NOT BETWEEN

IN = para testar se um valor está dentro de um determinado conjunto de


valores. Pode utilizar o operador IN em conjunto com o operador NOT
(formando a expressão NOT IN).

BETWEEN = para testar se um valor está entre uma determinada faixa de


valores.

NOT IN – Este operador, ao contrário do IN, permite obter como resultado


o valor de uma coluna que não pertence a uma determinada lista de
elementos.

NOT BETWEEN – O operador NOT BETWEEN, ao contrário do


anteriormente descrito, permite consultar os valores que não se encontram
em uma determinada faixa.

137
OPERADOR HAVING

O operador HAVING deverá ser utilizado em conjunto com a declaração


SELECT e sua função será a de estabelecer um critério extra de
agrupamento ou seleção de valores, quando utilizando-se a cláusula
GROUP BY. Pode-se entender a declaração HAVING como sendo uma
cláusula WHERE para a declaração GROUP BY.

SELECT descricao, unidades=sum(qtdade)


FROM produto, venda
WHERE produto.cod = venda.produto
GROUP BY descricao
HAVING sum(qtdade) > 12

138
OPERADOR DISTINCT

O operador DISTINCT possibilita que uma consulta retorne valores únicos,


sem repetições, para a coluna de dados.Este operador deve ser utilizado
em conjunto com a declaração SELECT.

SELECT DISTINCT (coluna)


FROM tabela
WHERE condição

139
DESCRIBE – SHOW COLUMNS FROM

DESCRIBE á um atalho para SHOW COLUMNS FROM.


Lista a estrutura de uma tabela.

140
MySQL INNODB - Introdução e principais características

Conhecer a arquitetura do MySQL é de fundamental importância para


entendermos o que é um "Storage Engine", sendo assim, antes de
qualquer conceituação, vejamos como são e onde ficam as
"Engenharias de Armazenamento". Daqui por diante, trataremos os
"Storage Engines" pela sua tradução, Engenharia de Armazenamento.

141
A arquitetura interna do MySQL é provida de duas camadas principais, a
primeira camada, que é a camada de parser e otimização de consultas
SQL e a segunda que é onde estão conectadas as Engenharias de
Armazenamento de forma modular. Assim como o INNODB, existem outras
Engenharias como MyISAM, FEDERATED, MERGE, MEMORY, BDB,
ARCHIVE, CSV, EXAMPLES, BLACKHOLE e a novidade do MySQL 6.0, a
FALCON, cada qual com suas características próprias. A Figura 01 ilustra
as camadas citadas e outros componentes participantes

142
143
As Engenharias de Armazenamento funcionam como plugins, que são,
mediante a alguma configuração, adicionados ao servidor MySQL que
apresenta uma estrutura 100% modular. São estas engenharias que
gerenciam diretamente os arquivos no disco. Cada tabela que é criada
utilizando a Engenharia de Armazenamento INNODB, armazena no
diretório do banco de dados, sob o diretório de dados (datadir), um arquivo
.frm, este por sua vez armazena a estrutura da tabela. Os dados e os
índices ficam localizados em um tablespace sobre o datadir. O INNODB
tem um tablespace padrão de nome ibdata que é utilizado para
armazenar índices e dados de todas as tabelas de todos os bancos de
dados contidos em um servidor MySQL. Podemos também, configurar
tablespaces em locais personalizados do filesystem ou utilizar um
tablespace para cada tabela criada.

144
Principais Características do INNODB

INNODB dá suporte à transações e é totalmente adequada às


propriedades ACID. O multi-versionamento é utilizado para garantir o
isolamento de uma transação em relação à outra;

INNODB provê auto_recovery após um crash ou queda no servidor


onde o MySQL roda;

INNODB tem suporte a integridade referencial, ou seja, tem suporte a


criação de FOREIGN KEY, incluindo cascateamentos em DELETE e
UPDATE. As propriedades de integridade referencial suportados pelo
INNODB são: { RESTRICT | CASCADE | SET NULL | NO ACTION }

145
SISTEMA DE GERENCIAMENTO
DE BANCO DE DADOS
RELACIONAL
Charles Emerson Machado

Charles.emerson.machado@gmail.com

146
Revisão com exercícios dos comandos da 4º Aula

147
SISTEMA DE GERENCIAMENTO
DE BANCO DE DADOS
RELACIONAL
Charles Emerson Machado

Charles.emerson.machado@gmail.com

148
PROJETO DE BANCO DE DADOS: CLINICA MÉDICA
Competências: Analisar e aplicar o resultado da modelagem
de dados; Habilidades: Implementar as estruturas modeladas usando
banco de dados; Bases Tecnológicas: Administração de banco de
dados; Ambientes/ferramentas de gerenciamento de bancos de dados.

SITUAÇÃO

Pretende-se criar uma base de dados que permita gerir uma parte da informação
de uma clinica de saúde.
Fundamentalmente a base de dados deverá guardar a informação relativa aos
doentes que frequentam a clínica (nome, morada, telefone e numero de
beneficiário) e dos médicos que lá trabalham (nome,morada,contacto e
especialidade).
Para além disso o sistema deverá registar as marcações de consultas de cada
paciente para um determinado médico sabendo que esse médico só pratica uma
determinada especialidade.

149
MODELO DE NEGÓCIO: CLINICA MÉDICA

O médico que atende na clínica é previamente cadastrado pelo número do


CRM, (composto por 5 dígitos numéricos obrigatórios, deve ser um dado
único e obrigatório para cada registro de médico na clínica), pelo nome
(campo indexado obrigatório para todos os registros), pelo endereço
(completo), por um número de celular (sem DDD) e pelo CPF (campo
obrigatório e não repetido composto por 11 dígitos numéricos obrigatórios).
Cada médico “pode” consultar um ou mais pacientes.
Cada consulta registrará a data (10/01/08), a hora (08:00), o valor da
consulta, o diagnóstico completo e se foi pedido exame ou não.

150
Os pacientes consultados na clinica são identificados pelo nome (campo
“índice” obrigatório para todos os registros), endereço, telefone (com DDD)
e CPF, (campo índice não repetido composto por 11 dígitos numéricos
obrigatórios – ATENÇÃO pode existir pacientes sem CPF). Um paciente
“deve” ser consultado por um ou mais médicos.
As especialidades registram apenas a especialidade (Clinica Geral,
Pediatria, Ortopedia, etc. Dado obrigatório para cada registro de
especialidade e que não pode ser repetido), atendida na clinica. Um
médico “deve” ter uma e somente uma especialidade. Enquanto uma
especialidade “pode” ser relacionada a um ou mais médicos.

151
Um paciente “pode” ser um e somente um paciente privado, isto é, possui convênio
médico com algum plano de saúde. Os pacientes privados são registrados pelo
nome do plano (Golden Cross, Unimed, etc. campo indexado e que permite
repetição), pelo Número do Contrato (dado indexado alfanumérico obrigatório que
pode ser repetido, de 8 dígitos obrigatórios), e se o paciente é Titular do plano de
saúde (sim ou não). Um paciente privado “deve” ser um e somente um paciente na
clínica.
OBS: Campos com mais de sete caracteres não serão usados como chave
primária. Campos “criados” como identificadores únicos (chave primária) serão
controlados automaticamente pelo sistema, campos nativos NÃO serão
preenchidos automaticamente.

Os dados da especialidade e do medico são de responsabilidade da diretoria do


hospital, enquanto os dados do paciente e da consulta são da competência do
atendimento.

152
153
154
155
MODELO ENTIDADE - RELACIONAMENTO

O objetivo da modelagem de dados é possibilitar a apresentação de uma


visão única e não redundante dos dados de uma aplicação. No
desenvolvimento da aplicação de um BD, o modelo Entidade-
Relacionamento (MER) é o mais utilizado para representação e
entendimento dos dados que compõe a essência de um sistema de
informação.
O MER representa as informações do universo sendo modelado como
objetos, denominados entidades, e representa as relações entre as
informações como sendo relações entre esses objetos, denominadas
relacionamentos.
O Projeto Conceitual do BD, utilizando o MER pode ser representado
graficamente pelo DER (Diagrama Entidade-Relacionamento).

156
ENTIDADES E CONJUNTO DE ENTIDADES

Uma entidade é um objeto que existe no universo sendo modelado e é


distinguível dos demais objetos. Um grupo de entidades que possuem
características semelhantes formam um conjunto de entidades.
Em um conjunto de entidades são representadas a princípio, todos os
elementos do mundo real referidos pelo conjunto. Para evitar a
redundância, cada objeto do mundo real deve ser representado
preferencialmente por uma única entidade de um único conjunto de
entidades.

Representação gráfica no DER


Um conjunto de entidades é representado por um retângulo com seu nome
dentro. O nome deve ser um substantivo no singular.

157
Exemplo: suponha uma empresa onde trabalham vários empregados. João
da Silva e Carla Gomes são empregados dessa empresa. São entidades o
conjunto de todos os empregados da empresa, formando um conjunto de
entidades Chamado Empregado.
Representação gráfica :

158
REPRESENTAÇÃO GRÁFICA NO DER

O atributo pode ser representado por uma elipse com seu nome dentro
desta. A elipse deve estar ligada ao conjunto de entidades a qual pertence
o atributo através de uma linha simples. Os atributos simples e os
monovalorados são representados por uma elipse simples. Os atributos
multivalorados são representados por uma elipse dupla e os derivados por
uma elipse pontilhada.
Voltando ao exemplo da empresa, quais informações sobre os empregados
são importantes para os nossos propósitos? Informações como número de
matrícula, nome, endereço, salário, sexo, data de nascimento, etc.

159
CHAVES DO CONJUNTO DE ENTIDADES

Precisamos especificar como distinguir cada entidade de um conjunto de


entidades usando seus atributos. Uma chave candidata de um conjunto de
entidades é um conjunto de um ou mais atributos, que juntos permitem
identificar unicamente cada entidade.
Uma chave candidata deve ser um conjunto minimal de atributos, isto é,
não devem possuir subconjuntos que também são chaves candidatas. Um
conjunto de entidades pode possuir várias chaves candidatas.
Uma chave primária de um conjunto de entidades é uma chave candidata
escolhida como principal mecanismo de identificação das entidades do
conjunto de entidades.

160
Representação gráfica no DER

Os atributos que formam a chave primária têm seu nome sublinhado. No exemplo
da empresa cada empregado pode ser identificado unicamente pelo seu número de
matrícula, pois não existem dois empregado com o mesmo número. Assim, o
atributo número de matrícula pode se tornar a chave primária da entidade
Empregado.

161
RELACIONAMENTO E CONJUNTO DE RELACIONAMENTOS

Precisamos representar também as relações que existem entre as


entidades. Estas relações são representadas pelos relacionamentos. Um
relacionamento é uma associação entre duas ou mais entidades.
Um conjunto de relacionamentos corresponde a um grupo de
relacionamentos do mesmo tipo. Assim, um relacionamento binário associa
duas entidades, um relacionamento ternário associa três entidades e assim
sucessivamente.

Considere novamente o exemplo da empresa. Existem vários projetos


desenvolvidos pela empresa. Esses projetos são entidades do conjunto de
todos os projetos da empresa, formando um conjunto de entidades
chamado Projeto. Os empregados trabalham nesses projetos, logo existe
uma relação trabalha_em entre os conjuntos de entidades Empregado e
Projeto (Empregado trabalha_em Projeto).

162
Representação gráfica no DER

Um conjunto de relacionamentos é representado por um losango, com o


nome do conjunto dentro, ligado por linhas aos conjuntos de entidades que
ele associa. O nome deve ser um substantivo no singular ou um verbo na
3ª pessoa do singular (mais apropriado).

163
Atributos dos Conjuntos de Relacionamentos

Um conjunto de relacionamentos pode possuir atributos que descrevem a


associação das entidades. Voltando ao exemplo, cada empregado trabalha
um certo número de horas em um determinado projeto. Logo, o número de
horas trabalhadas por um Empregado em um Projeto é um atributo do
relacionamento trabalha_em.

Representação gráfica no DER

Atributos de conjunto de relacionamentos são representados tal como


atributos de conjuntos de entidades, porém são ligados por linhas ao
losango.

164
165
Propriedades de Relacionamentos

O MER permite representarmos algumas restrições sobre dados, e regras


que existem no universo que está sendo modelado e que os dados do BD
devem obedecer.

Cardinalidade dos Conjuntos de Relacionamentos

166
A cardinalidade de um conjunto de relacionamentos expressa o número de
entidades de um conjunto de entidades E1 que podem estar associadas a
uma entidade do outro conjunto de entidades E2, através daquele conjunto
de relacionamentos R.

Para um conjunto de relacionamentos binários a cardinalidade pode ser:

167
um para um (1:1): uma entidade de E1 pode estar associada no máximo
a uma entidade de E2 através de R; e uma entidade de E2 pode estar
associada a no máximo uma entidade de E1, através de R.

Ex.: Um vendedor ocupa um único escritório e um escritório pode ser


ocupado por um único vendedor.

168
um para muitos (1:N): uma entidade de E1 pode estar associada a várias
entidades E2; e uma entidade de E2 pode estar associada no máximo uma
entidade de E1.
Ex. Um vendedor atende muitos clientes. Porém, cada cliente tem um
vendedor específico.

169
muitos para um (N:1): uma entidade de E1 pode estar associada a no
máximo uma entidade de E2; e uma entidade de E2 pode estar associada
a várias entidades de E1.

170
muitos para muitos (N:N) : uma entidade de E1 pode estar associada a
várias entidades de E2; e uma entidade de E2 pode estar associada a
várias entidades de E1.

Ex.: Um vendedor atende muitos clientes, e um cliente pode ser atendido


por diversos vendedores.

Na prática, o relacionamento n:n é dividido em duas relações 1:n e uma


nova entidade é criada para representar o relacionamento.

171
172
CHAVES DAS RELAÇÕES

Uma chave candidata de uma relação é o menor conjunto possível de


atributos que identificam unicamente uma tupla da relação. Uma relação
pode ter várias chaves candidatas.

Uma chave primária (Primary Key - PK) de uma relação é uma chave
candidata escolhida como a principal forma de identificação das tuplas. As
demais candidatas são chaves secundárias.

A chave primária que faz parte dos atributos de uma relação é


chamada de chave estrangeira (Foreign Key - FK).

173
SISTEMA DE GERENCIAMENTO
DE BANCO DE DADOS
RELACIONAL
Charles Emerson Machado

Charles.emerson.machado@gmail.com

174
EXERCÍCIOS SOBRE CRIAÇÃO DE TABELAS E SELECT

175
SISTEMA DE GERENCIAMENTO
DE BANCO DE DADOS
RELACIONAL
Charles Emerson Machado

Charles.emerson.machado@gmail.com

176
REVISÃO DE CONCEITOS

CHAVE PRIMÁRIA

Chaves primárias (em inglês Primary Keys ou PK) sob o ponto de


vista de um banco de dados relacional, referem-se aos conjuntos de um
ou mais campos, cujos valores, considerando a combinação de valores
de todos os campos da tupla, nunca se repetem e que podem ser
usadas como um índice para os demais campos da tabela do banco de
dados. Em chaves primárias, não pode haver valores nulos nem
repetição de tuplas.

177
CHAVE PRIMÁRIA
Simplificando, quando a chave primária é simples, ou seja, é formada por
um único campo da tabela, esse campo não pode ter dois ou mais
registros de mesmo valor, e também não pode conter nenhum registro
nulo. Se a chave primária é composta, ou seja, formada por mais de um
campo, os valores de cada campo podem se repetir, mas não a
combinação desses valores. Exemplo: a tabela 'Livros_Autores' tem
como chave primária (cod_livro, cod_autor). Podem existir nessa tabela
os registros:

(5, 9), (5, 10), (4, 9), (9, 5)

Mas não podem existir dois registros (5, 9).

178
CHAVE PRIMÁRIA

Podemos inserir uma chave primária durante ou após a criação da tabela.


Com a tabela já criada, o campo que escolhermos para ser a chave
primária deve ter a opção NOT NULL adicionada.
Na definição de chave primária, usamos o comando ALTER TABLE para
inserirmos e excluirmos uma primary key.

179
CHAVE ESTRANGEIRA - CHAVE SECUNDÁRIA

O conceito de Chave estrangeira ou Chave secundária em uso de


banco de dados se refere ao tipo de relacionamento entre as tabelas de
dados do banco de dados. Uma chave estrangeira é chamada quando há
o relacionamento entre duas tabelas. Sempre em chave estrangeira vai
haver relacionamentos entre tabelas, por exemplo, se uma tabela que tem
uma chave primária de outra tabela.

180
CHAVE ESTRANGEIRA - CHAVE SECUNDÁRIA
Uma chave externa ou estrangeira é um atributo ou uma combinação de
atributos numa relação R2, cujos valores são necessários para equivaler
à chave primária de uma relação R1.
Uma chave estrangeira é um campo, que aponta para a chave primária
de outra tabela ou da mesma tabela. Ou seja, passa a existir uma relação
entre tuplas de duas tabelas ou de uma única tabela. A finalidade da
chave estrangeira é garantir a integridade dos dados referenciais, pois
apenas serão permitidos valores que supostamente vão aparecer na
base de dados.
Esse tipo de atributo não permite exclusão, modificação e/ou inserção de
dados em tabelas que estejam dependentes umas das outras("foreign
key"), o que requer modificadores especiais, como cascade, por exemplo.
Isso também exige uma maior atenção do administrador da base de
dados, quanto à própria manipulação dos dados.

181
RELACIONAMENTOS

Um relacionamento, do Modelo de Entidades e Relacionamentos é


traduzido para a criação de atributos com chaves externas do Modelo
Relacional. Esta tradução é feita ligando-se um campo de uma tabela X
com um campo de uma tabela Y, por meio da inclusão do campo chave
da tabela Y como um campo (conhecido como chave estrangeira) da
tabela X.
Por meio das chaves estrangeiras, é possível implementar restrições
nos SGBDR.

Existem alguns tipos de relacionamentos possíveis no MER:

182
RELACIONAMENTOS

 Um para um (1 para 1) - indica que as tabelas têm relação unívoca


entre si. Você escolhe qual tabela vai receber a chave estrangeira;

 Um para muitos (1 para N) - a chave primária da tabela que tem o


lado 1 vai para a tabela do lado N. No lado N ela é chamada de
chave estrangeira;

 Muitos para muitos (N para N) - quando tabelas têm entre si relação


n..n, é necessário criar uma nova tabela com as chaves primárias das
tabelas envolvidas, ficando assim uma chave composta, ou seja,
formada por diversos campos-chave de outras tabelas. A relação
então se reduz para uma relação 1..n, sendo que o lado n ficará com
a nova tabela criada.

183
RELACIONAMENTOS

Os relacionamentos 1 para 1 e 1 para N podem ser mapeados


diretamente em chaves estrangeiras nas tabelas originais. Já o
relacionamento N para N exige o uso de uma tabela auxiliar.

184
RELACIONAMENTOS

Um conjunto de passos pode ser seguido para identificar a cardinalidade


de um relacionamento entre duas entidades. Deve-se ter em mente que
a análise de todo relacionamento entre entidades é bidirecional. Assim,
deve se analisar como é determinada a cardinalidade existente entre,
por exemplo, as entidades cliente e pedido (ver figura 1).

185
RELACIONAMENTOS

Passo 1: o primeiro passo será determinar a cardinalidade


existente entre cliente e pedido. Considerando a navegabilidade no
sentido cliente pedido, realiza-se a seguinte pergunta: um cliente pode
fazer quantos pedidos? a resposta é: 1 cliente pode realizar vários
pedidos. então, a cardinalidade existente será de 1:n, pois a palavra
“vários” em modelagem relacional é identificada pela letra n (ver figura
2).

186
RELACIONAMENTOS

Passo 2: para realizar o segundo passo é necessário inverter a


pergunta. Neste caso, determina-se a cardinalidade existente entre
pedido e cliente. Percebe-se que se inverte a navegabilidade e realiza-
se a seguinte pergunta: um pedido pode possuir quantos clientes? a
resposta é: 1 pedido pode possuir 1 cliente. dessa forma, a
cardinalidade existente será 1:1 (ver figura 12).

187
RELACIONAMENTOS

Passo 3: agora se tem em mãos a cardinalidade completa, ou seja,


nas duas direções. O próximo passo é identificar a cardinalidade
máxima para cada entidade definindo assim o relacionamento entre
elas. Na posição vertical (identificada pelas elipses na figura 3), tem-se
a cardinalidade encontrada para cada entidade. No caso de cliente,
a maior cardinalidade será 1 e para pedido será n.

188
RELACIONAMENTOS

Passo 4: por fim, na figura abaixo exibe-se o relacionamento final


existente entre as duas entidades. Aqui temos uma dica importante:
após a implementação do modelo físico, o atributo cod_cliente será
“duplicado” na tabela pedido, garantindo assim o relacionamento entre
as duas entidades. Isso quer dizer que um cliente não poderá ser
eliminado enquanto seus respectivos pedidos também não forem. essa
é a terminologia padrão, porém pode ser ajustada a cada caso.

189
SISTEMA DE GERENCIAMENTO
DE BANCO DE DADOS
RELACIONAL
Charles Emerson Machado

Charles.emerson.machado@gmail.com

190
MODELO ENTIDADE RELACIONAMENTO - LOJA

191
MODELO ENTIDADE RELACIONAMENTO - LOJA

Execução dos scripts encaminhados por e-mail.


Neste além da criação de todo o banco e sua estrutura, ocorreu a inserção
de alguns dados em determinadas tabelas.

192
SISTEMA DE GERENCIAMENTO
DE BANCO DE DADOS
RELACIONAL
Charles Emerson Machado

Charles.emerson.machado@gmail.com

193
JUNÇÕES

Consultas a uma única tabela são usadas; porém, é nas consultas que
referenciam duas ou mais tabelas que estão os anseios de quem utiliza
um gerenciador de bancos de dados.
Para realizar estas consultas, precisa-se fazer os chamados JOINs, ou
seja, indicar ao gerenciador como ele encontrará as informações
desejadas informando os relacionamentos entre elas. Estes
relacionamentos estão indicados nas tabelas na forma de chaves
estrangeiras, que são os campos que formam as chaves primárias das
tabelas, que, por sua vez, contêm, as informações que se deseja
conseguir.

194
Conexão Cartesiana

Pega cada valor da primeira tabela e emparelha com cada valor da


segunda tabela.

SELECT
nome_tabela1.nome_coluna1,
nome_tabela2.nome_coluna1
FROM
nome_tabela1 CROSS JOIN nome_tabela2

195
CONEXÕES DE IGUALDADE

Combina os registros de duas tabelas usando operadores de


comparação em uma condição.
Colunas são retornadas apenas onde as linhas conectadas combinam
com a condição.

SELECT
nome_tabela1.nome_coluna1,
nome_tabela1.nome_coluna2,
nome_tabela2.nome_coluna1,
nome_tabela2.nome_coluna2
FROM
nome_tabela1 INNER JOIN nome_tabela2 ON
nome_tabela1.nome_coluna1 = nome_tabela2.nome_coluna1

196
CONEXÃO ESQUERDA

Pega todas as linhas da tabela esquerda e combina com as linhas da


tabela direita. É útil quando a tabela esquerda e a tabela direita
possuem um relacionamento um-para-muitos.
O grande segredo de entender as conexões externas é saber qual
tabela está à esquerda e qual está à direita.
Na conexão esquerda, a tabela que vem depois do FROM e ANTES da
conexão é uma tabela ESQUERDA, e a tabela que vem DEPOIS da
conexão é uma tabela DIREITA.

SELECT
nome_tabela1.nome_coluna1,
nome_tabela2.nome_coluna1
FROM
nome_tabela1 LEFT JOIN nome_tabela2 ON
nome_tabela1.nome_coluna1 = nome_tabela2.nome_coluna1

197
CONEXÃO DIREITA

A conexão direita é a mesma coisa que a conexão esquerda, exceto


quando compara a tabela direita com a esquerda. A conexão direita
avalia a tabela direita em contraposição à tabela esquerda.
Na conexão esquerda, a tabela que vem depois do FROM e ANTES da
conexão é uma tabela DIREITA, e a tabela que vem DEPOIS da
conexão é uma tabela ESQUERDA.

SELECT
nome_tabela1.nome_coluna1,
nome_tabela2.nome_coluna1
FROM
nome_tabela1 RIGHT JOIN nome_tabela2 ON
nome_tabela1.nome_coluna1 = nome_tabela2.nome_coluna1

198
Quando um RIGHT ou LEFT JOIN apresenta a cláusula OUTHER, ele
indica ao gerenciador que deve recuperar todas as linhas de uma
tabela, inclusive aquelas que não possuírem linhas equivalentes na
outra.
Este método, portanto, previne e por vezes aponta erros de
inconsistência existentes no banco de dados ou causados por usuários
mal treinados em usa utilização.

Sintaxe:
[…] RIGHT OUTHER JOIN […]
[…] LEFT OUTHER JOIN […]

199
Existem algumas situações em que os JOINs são aplicados e resultam
em linhas com dados redundantes. Para solucionar este problema,
pode-se acrescentar ao comando SELECT a cláusula DISTINCT, que
forçaria o gerenciador a recuperar apenas valores diferentes, ignorando
assim, os que se repetissem.

Exemplo:
SELECT
DISTINCT nome_tabela1.nome_coluna1,
[…]

200
SUBCONSULTAS AO BANCO DE DADOS

Às vezes você precisa perguntar ao seu banco de dados mais que uma
pergunta. Ou pegar o resultado de uma consulta e usá-lo como entrada
para outra consulta. É aí que as subconsultas entram.
Elas irão ajudar a evitar dados duplicados, fazer suas consultas mais
dinâmicas.

Sintaxe para encontrar resultados à partir de outra consulta:

SELECT
nome_coluna1,
nome_coluna2
FROM
nome_tabela
WHERE
nome_coluna1 IN (SELECT nome_coluna FROM nome_tabela)

201
Sintaxe para mostrar colunas criadas em outra consulta:

SELECT
nome_coluna_select1,
nome_coluna_select2
FROM
(SELECT
nome_coluna1,
nome_coluna2
FROM
nome_tabela
) AS nome_tabela_criada

202
Sintaxe para mostrar uma coluna dentro das colunas de uma consulta:

SELECT
nome_coluna1,
(SELECT nome_coluna2
FROM nome_tabela2
WHERE nome_tabela1.nome_coluna1 = nome_coluna2),
nome_coluna3
FROM
nome_tabela1

203
SINTAXE DE ANALYZE TABLE

O MySQL utiliza a distribuição de chaves armazenadas para decidir em


que ordem tabelas devem ser unidas quando alguém faz
um join em alguma coisa diferente de uma constante.

analyze table cliente;

204
EXPLAIN (Obter informações sobre uma SELECT)

explain select * from cliente, cidade;

Quando uma instrução SELECT for precedida da palavra chave


EXPLAIN, o MySQL explicará como ele deve processar a SELECT,
fornecendo informação sobre como as tabelas estão sendo unidas e em
qual ordem.
Com a ajuda de EXPLAIN, você pode ver quando devem ser
adicionados índices à tabelas para obter uma SELECT mais rápida
que utiliza índices para encontrar os registros.

205
Para ligações mais complexas, EXPLAIN retorna uma linha de
informação para cada tabela utilizada na instrução SELECT. As tabelas
são listadas na ordem que seriam lidas. O MySQL soluciona todas as
joins utilizando um método multi-join de varedura simples.
Isto significa que o MySQL lê uma linha da primeira tabela, depois
encontra uma linha que combina na segunda tabela, depois
na terceira tabela e continua. Quando todas tabelas são processadas,
ele exibe as colunas selecionadas e recua através da lista
de tabelas até uma tabela na qual existem registros coincidentes for
encontrada. O próximo registro é lido desta tabela e o processo
continua com a próxima tabela.

206
VIEWS

Uma view é uma maneira alternativa de observação de dados de uma ou


mais entidades (tabelas), que compõem uma base de dados. Pode ser
considerada como uma tabela virtual ou uma consulta armazenada.

Sintaxe:
CREATE [OR REPLACE] [ALGORITHM = algorithm_type] VIEW AS
SELECT
nome_coluna1
FROM
nome_tabela [WITH [CASCADED | LOCAL] CHECK OPTION]

Testando:

SELECT * FROM nome_view

207
VIEWS

E alguns casos, as Views são atualizáveis e podem ser alvos de


declaração INSERT, UPDATE e DELETE, que na verdade modificam sua
"based tables".
Os benefícios da utilização de Views, além dos já salientados, são:

• Uma View pode ser utilizada, por exemplo, para retornar um valor
baseado em um identificador de registro;
• Pode ser utilizada para promover restrições em dados para aumentar
a segurança dos mesmos e definir políticas de acesso em nível de
tabela e coluna. Podem ser configurados para mostrar colunas
diferentes para diferentes usuários do banco de dados;
• Pode ser utilizada com um conjunto de tabelas que podem ser
unidas a outros conjuntos de tabelas com a utilização de JOIN´s ou
UNION.

208
VIEWS

view_name: é o nome que damos ao objeto View que criarmos.


select_statement: é a sua declaração SELECT e indica a forma na qual
você deseja que os dados sejam retornados. Tal declaração deverá
indicar a forma a qual você deseja retornar os dados, podendo ser
utilizado funções, JOIN´s e UNION. Podem ser utilizadas quaisquer
tabelas ou views contidas no servidor de bancos de dados MySQL,
observando a questão de nomes totalmente qualificados ou não.
OR REPLACE: pode ser utilizada para substituir uma View de mesmo
nome existente no banco de dados ao qual ela pertence. Pode-se
utilizar ALTER TABLE para o mesmo efeito;

209
VIEWS

ALGORITHM: essa cláusula define qual algoritmo interno utilizar para


processar a View quando a mesma for invocada. Estes podem ser
UNDEFINED (cláusula em branco), MERGE ou TEMPTABLE.

WITH CHECK OPTION: todas as declarações que tentarem modificar


dados de uma view definida com essa cláusula serão revisadas para
checar se as modificações respeitarão a condição WHERE, definida no
SELECT da View.

210
VIEWS

Views com WITH CHECK OPTION

Podemos ainda trabalhar algumas restrições na criação de algumas


Views, como utilizar a opção WITH CHECK OPTION. Atribuindo esta
opção na criação de uma View significa que atualização que são
emitidas terão que se encaixar às condições definidas na cláusula
WHERE da consulta SELECT.

211
TRANSAÇÕES

SET AUTOCOMMIT=0;
START TRANSACTION;

Comandos

COMMIT | ROLLBACK;

212
STORED PROCEDURES

As Stored Procedures são procedimentos formados por um conjunto de


instruções SQL que executam tarefas específicas dentro do banco de
dados.
O uso de Stored Procedures pode aumentar o desempenho de algumas
situações, uma vez que os dados não precisam trafegar pela rede entre
o servidor e a estação cliente. No entanto, isso sobrecarrega o
computador servidor, que deve ter capacidade suficiente para suportar o
processamento extra.

Sintaxe:

CREATE PROCEDURE nome_procedure (IN parâmetro1 tipo_dado)


BEGIN
Comandos
END

213
procedimentos armazenados ou Stored Procedures são programas
armazenados no servidor de banco de dados, no caso o MySQL, para
que ao serem chamados executem alguma lógica, retornando ou não
algum resultado. Estes aceitam parâmetros que por sua vez podem ser
de entrada, saída ou entrada e saída. Mas, em alguns casos, é
necessário armazenar alguma informação em variáveis ou mesmo
executar uma conferência por exemplo de uma instrução INSERT.
Digamos que desejamos efetuar um cálculo com base em um valor
armazenado no banco de dados. Facilmente podemos criar ou definir
uma variável em meio ao processamento e armazenar o valor de uma
coluna de uma tabela em uma dessas variáveis definidas pelo usuário.

214
Definição
Uma variável que é definida pelo usuário, também conhecida como user
variables, é escrita precedida pelo símbolo @ (arroba) e pode receber
através da declaração SET com os valores do tipo inteiro (INT), real
(FLOAT), string ou um valor NULL, que representa um fragmento de
dado sem definição e sem valor. Não vamos falar agora sobre NULL
pois seria necessário escrever um outro artigo. Variáveis do usuário são
diferentes de variáveis locais.
Podemos atribuir um valor a uma variável definida pelo usuário
utilizando os sinais igual (=) ou o sinal de igual com notação Pascal (:=).
Qualquer dos dois poderá ser usado levando em conta o contexto ao
estamos atribuindo tal valor. Por exemplo, se somente queremos
inicializar uma variável atribuindo a esta um valor para ser utilizado em
meio a um processamento ou mesmo guardar um valor de um campo
de uma tabela para uma utilização futura, podemos fazer como mostra
abaixo.

215
SET @teste = ‘Curso Técnico Web – Senac TI';

select @teste;

Uma observação importante a fazer é que, caso venhamos a utilizar


uma variável do usuário que não tenha sido inicializada e nem tenha
recebido anteriormente um valor, o processamento que utilizar-se desta
variável será prejudicado pois ela terá um valor NULL e uma
comparação de qualquer valor, numérico ou string com NULL é igual a
NULL

SET @VALOR1 = 'FLORIPA';


0 para valores diferentes
SET @VALOR2 = 'SÃO JOSE';
1 para valores iguais.
SELECT @VALOR1 = @VALOR2;

216
Variáveis do usuário são específicas de uma conexão, não estando
disponíveis ou visíveis para outras conexões. No MySQL 5.0++,
variáveis do usuário não são Case Sensitive, ou seja, @VAR e @var
são a mesma coisa.

217
Variáveis do Usuário + Procedimentos Armazenados

Agora que já sabemos lidar com a parte conceitual das variáveis do


usuário, podemos trabalhar com estas em meio aos procedimentos
armazenados, interagido com servidor de bancos de dados MySQL
através da linha de comando.
Primeiramente, vamos criar um exemplo para efetuar a inserção de um
registro, um valor então será enviado ao procedimento que o receberá
como parâmetro de entrada (IN). Após a inserção do registro,
utilizaremos uma estrutura condicional para checar o retorno da função
LAST_INSERT_ID() que retornará seu valor em uma variável do usuário
que criaremos internamente ao procedimento. Caso o valor retornado
por esta função seja maior que zero, o cadastro foi efetuado com
sucesso.

218
CREATE PROCEDURE BANCO_INSERT (V_NOME CHAR(100))
BEGIN
IF (V_NOME !='')THEN
-- Sendo v_nome diferente de vazio, continuamnos com o programa.
insert into cliente set cliente_nome = v_nome;
-- selecionamos o last_insert_id() into a user var.
select last_insert_id() into @var;
if ((@var >0) or (@var = null)) then
select 'Cadastro efetuado' as msg;
else
select 'Falhas no cadastro' as msg;
end if;
else
select 'Um nome precisa ser informado!' as msg;
end if;
end;

219
call banco_insert('Coelho ricochete');

Este procedimento, ainda de forma básica, pode ser utilizado com


UPDATE e DELETE também.

220

Você também pode gostar