2014

Banco de Dados I
SISTEMA GERENCIADOR DE BANCO DE DADOS
RAYMUNDO THURY BARBOSA




1
Sumrio
INTRODUO............................................................................................................................................................... 3
Palavras do Professor ....................................................................................................................................................... 5
1. CONCEITOS GERAIS DE BANCO DE DADOS ....................................................................................................... 6
1.1 - Conceitos ............................................................................................................................................................. 6
1.2 - Representao Fsica do Banco de Dados............................................................................................................. 6
1.3 - Vises do Banco de Dados ................................................................................................................................... 6
1.4 - Vantagens do Banco de Dados em relao arquitetura tradicional ..................................................................... 7
1.4.1 - Definies ..................................................................................................................................................... 7
1.4.2 - Vantagens do Banco de Dados ..................................................................................................................... 8
2. BANCO DE DADOS .................................................................................................................................................. 9
3. SGBD x GA .............................................................................................................................................................. 10
4. CARACTERSTICAS GERAIS DE UM SGBD ........................................................................................................ 13
5. ARQUITETURA DE UM SGBD .............................................................................................................................. 16
5.1. Estrutura ............................................................................................................................................................. 16
5.2. Modelos de Dados............................................................................................................................................... 16
6. NORMALIZAO DE DADOS ............................................................................................................................... 17
6.1 - Primeira Forma Normal (1FN) ........................................................................................................................... 17
6.2 - Segunda Forma Normal (2FN) ........................................................................................................................... 18
6.4 - Terceira Forma Normal (3FN) ........................................................................................................................... 19
7. MODELO DE ENTEDIDADE E RELACIONAMENTO (MER) .............................................................................. 20
7.1 Definio ................................................................................................................................................................. 20
7.1.1 Entidade ............................................................................................................................................................ 21
7.1.2 Atributo ............................................................................................................................................................ 22
7.1.3 Domnio do Atributo ......................................................................................................................................... 22
7.2 - Representao Grfica ........................................................................................................................................... 23
7.2.1 Relacionamento ................................................................................................................................................ 23
7.3 - Cardinalidade de Relacionamentos ........................................................................................................................ 24
7.3.1 Relacionamento 1:1........................................................................................................................................... 26
7.3.2 Relacionamento 1:N ou N:1 .............................................................................................................................. 27
7.3.3 Relacionamento N:M ........................................................................................................................................ 28
7.4 - Atributos do Relacionamento ................................................................................................................................. 28
7.5 Grau do Relacionamento ....................................................................................................................................... 29
7.5.1 - Relacionamento Binrio ............................................................................................................................. 29
7.6 Dependncia Existencial .......................................................................................................................................... 31
7.7 Identificador de Entidade ......................................................................................................................................... 32
7.8 Esquema Relacional ................................................................................................................................................. 32
7.8.1 Relacionamento definido por dois tipos diferentes de entidades .................................................................... 32
7.8.2 Relacionamentos definidos por mais de dois tipos de entidades; ........................................................................ 32
7.8.3 Traduo de entidades Fracas ............................................................................................................................ 33
7.9 Exerccios ................................................................................................................................................................ 33
8. INTRODUO AOS TIPOS DE DADOS ................................................................................................................ 35
9. DESCRIO DOS COMANDOS PARA DEFINIO DE DADOS........................................................................ 36
9.1 Criando e removendo um banco de dados ................................................................................................................ 36




2
9.2 Criando e removendo tabelas .................................................................................................................................. 36
9.2.1 Entendendo o conceito de chaves primria ........................................................................................................ 37
9.2.2 Entendendo o conceito de chave estrangeira ...................................................................................................... 38
9.2.3 Removendo tabelas ........................................................................................................................................... 41






3

INTRODUO

O MySQL foi desenvolvido pela TCX em 1996. Atualmente a MySQL AB desenvolve o
programa. MySQL AB a companhia dos fundadores e principais desenvolvedores do MySQL. Eles
criaram-no porque precisavam de um banco de dados relacional que pudesse tratar grandes
quantidades de dados em mquinas de custo relativamente barato. O MYSQL um dos bancos de
dados relacionais mais rpidos do mercado, apresenta quase todas as funcionalidades dos grandes
bancos de dados. MySQL uma linguagem simples, em que voc facilmente pode gravar, alterar e
recuperar informaes num web site com segurana e rapidez O MYSQL executado,
principalmente, em sistemas que participam da filosofia UNIX, embora outros sistemas S.O tambm
fornecem suporte, como Windows, por exemplo.
O MYSQL um sistema de gerenciamento de banco de dados relacional multi-encadeado, de
cdigo fonte aberto e nvel corporativo. O MySQL no apenas um banco de dados, mas sim um
gerenciador de banco de dados. Com este SGBD (Sistema Gerenciador de Banco de Dados), tambm
pode ser utilizado para aplicaes corporativas, o qual, necessitam de vrias conexes simultneas,
que possibilita 101 conexes simultneas ou mais. Uma conexo o tempo que leva para o usurio
receber o dado solicitado.
MySQL a soluo robusta para quase todo tipo de aplicao, combine a estabilidade do
MySQL com seu baixo custo de propriedade e rapidamente voc ir consider-lo indispensvel. O
MySQL oferece o melhor cenrio de todos SGBD, executa em muitas plataformas, oferece um baixo
TCO (custo total de propriedade) e muito estvel.
O MySQL um sistema de gerenciamento de bancos de dados relacional.
Um banco de dados relacional armazena dados em tabelas separadas em vez de colocar todos
os dados um s local. Isso proporciona velocidade e flexibilidade.
O Servidor MySQL foi desenvolvido originalmente para lidar com bancos de dados muito
grandes de maneira muito mais rpida que as solues existentes e tem sido usado em ambientes
de produo de alta demanda por diversos anos de maneira bem sucedida. Apesar de estar em
constante desenvolvimento, o Servidor MySQL oferece hoje um rico e proveitoso conjunto de
funes. A conectividade, velocidade, e segurana fazem com que o MySQL seja altamente adaptvel
para acessar bancos de dados na Internet.
O Programa de Banco de Dados MySQL um sistema cliente/servidor que consiste de um
servidor SQL multitarefa que suporta acessos diferentes, diversos programas clientes e bibliotecas,




4
ferramentas administrativas e diversas interfaces de programao (API's). Tambm concedemos o
Servidor MySQL como uma biblioteca multitarefa que voc pode ligar sua aplicao para chegar a
um produto mais rpido, menor e mais facilmente gerencivel.






5
Palavras do Professor


Queridos Alunos,

Devido a carncia especificas de literatura destinada ao ensino de Banco de Dados e SQL (a
maioria das literaturas, associam o estudo do banco de dados associados a uma linguagem de
programao especificas), para estudantes, elaboramos a presente apostila, que no possuem o
intento de esgotar to abrangente volume de informaes, servindo to somente para estabelecer
um mnimo de conhecimentos destinados a introduzir o estudante no mundo dos Gerenciadores de
Banco de dados e da Linguagem SQL.
O arranjo ora apresentado visa dinamizar o ensina na disciplina proposta e se baseia
exclusivamente no contedo programtico proposto na plano de ensino.
Aproveita o mximo este material e bons estudos.


Professor Especialista Raymundo Thury Barbosa




6

1. CONCEITOS GERAIS DE BANCO DE DADOS
1.1 - Conceitos

a) Banco de Dados - Representa o arquivo fsico de dados, armazenado em dispositivos
perifricos, onde esto armazenados os dados de diversos sistemas, para consulta e
atualizao pelo usurio.
b) Tabelas Lgicas - Representam as estruturas de armazenamento de dados (arquivos) dos
sistemas.
c) S.G.D.B. (Sistema Gerenciador de Banco de Dados) - o software responsvel pelo
gerenciamento (armazenamento e recuperao) dos dados no Banco de Dados.
d) 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.
e) Contedo do campo - o valor do campo armazenado no Banco de Dados. Ex. O valor do
campo "nome do cliente" sem estar, momentaneamente, sendo utilizado.
f) Informao - 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?
g) Modelo de Banco de Dados: Modelo Relacional, Modelo Hierrquico e Modelo em Rede.
Representa a estrutura fsica no qual o armazenamento dos dados foram projetados. O
modelo identifica a estrutura interna de recuperao e armazenamento dos dados no qual o
SGBD foi projetado.

1.2 - Representao Fsica do Banco de Dados













1.3 - Vises do Banco de Dados


TABELAS
LGICAS
INFORMAES PARA
O USURIO
BANCO DE DADOS
(Arquivo Fsico)




7
a) Viso Interna - aquela vista pelo responsvel pela manuteno e desenvolvimento do SGBD.
Existe a preocupao com a forma de recuperao e manipulao dos dados dentro do Banco
de Dados.
b) Viso Conceitual - aquela vista pelo analista de desenvolvimento e pelo administrador das
bases de dados. Existe a preocupao na definio de normas e procedimentos para
manipulao dos dados, para garantir a sua segurana e confiabilidade, o desenvolvimento
de sistemas e programas aplicativos e a definio no banco de dados de novos arquivos e
campos. Na viso conceitual, existem 2 (duas) linguagens de operao que so:
c) Linguagem de definio dos dados (DDL) - Linguagem que define as aplicaes, arquivos e
campos que iro compor o banco de dados (comandos de criao e atualizao da estrutura
dos campos dos arquivos).
d) Linguagem de manipulao dos dados (DML) - Linguagem que define os comandos de
manipulao e operao dos dados (comandos de consulta e atualizao dos dados dos
arquivos).
e) Viso Externa - aquela vista pelo usurio que opera os sistemas aplicativos, atravs de
interfaces desenvolvidas pelo analista (programas), buscando o atendimento de suas
necessidades.















1.4 - Vantagens do Banco de Dados em relao arquitetura tradicional
1.4.1 - Definies

Sistema Tradicional - So aqueles em que os dados do sistema esto armazenados fisicamente
separados um do outro. O acesso feito pelos programas de aplicao, associando o nome externo
dos arquivos e definindo todo o registro independente da utilizao dos campos.
UTILIZAO DAS
APLICAES DESENVOLVIDAS
VISO EXTERNA
VISO CONCEITUAL
DESENVOLVIMENTO DE APLICAES

UTILIZANDO RECURSOS DO S.G.B.D.
DESENVOLVIMENTO DO S.G.B.D. VISO INTERNA




8
Sistema de Banco de Dados - aquele em que os dados so definidos para o S.G.B.D., atravs
da DDL (linguagem de definio de dados). Fisicamente esto armazenados em um nico local, sendo
o acesso realizado apenas atravs do S.G.B.D. Nos programas de aplicao, necessrio apenas
definir os campos que sero utilizados pelo programa.

1.4.2 - Vantagens do Banco de Dados

a) Reduo ou Eliminao de Redundncias - Possibilita a eliminao de dados privativos de
cada sistema. Os dados, que eventualmente so comuns a mais de um sistema, so
compartilhados por eles, permitindo o acesso a uma nica informao sendo consultada por
vrios sistemas.
b) Eliminao de Inconsistncias - Atravs do armazenamento da informao em um nico local
com acesso descentralizado e, sendo compartilhada vrios sistemas, os usurios estaro
utilizando uma informao confivel. A inconsistncia 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 no o atualizou em outro. Quando o dado armazenado em um nico local e
compartilhado pelos sistemas, este problema no ocorre.
c) Compartilhamento dos Dados - Permite a utilizao simultnea e segura de um dado, por
mais de uma aplicao ou usurio, independentemente da operao que esteja sendo
realizada. Deve ser observada apenas o processo de atualizao concorrente, para no gerar
erros de processamento (atualizar simultaneamente o mesmo campo do mesmo registro).
Os aplicativos so por natureza multiusurio.
d) Restries de Segurana - Define para cada usurio o nvel de acesso a ele concedido (leitura,
leitura e gravao ou sem acesso) ao arquivo e/ou campo. Este recurso impede que pessoas
no autorizadas utilizem ou atualizem um determinado arquivo ou campo.
e) Padronizao dos Dados - Permite que os campos armazenados na base de dados sejam
padronizados segundo um determinado formato de armazenamento (padronizao de
tabela, contedo de comps, etc.) e ao nome de variveis seguindo critrios padres
preestabelecido pela empresa. Ex. Para o campo "Sexo" somente ser permitido
armazenamento dos contedos "M" ou "F".
f) Independncia dos Dados - Representa a forma fsica de armazenamento dos dados no
Banco de Dados e a recuperao das informaes pelos programas de aplicao. Esta




9
recuperao dever ser totalmente independente da maneira com que os dados esto
fisicamente armazenados. Quando um programa retira ou inclui dados o SGBD compacta-os
para que haja um menor consumo de espao no disco. Este conhecimento do formato de
armazenamento do campo totalmente transparente para o usurio. A independncia dos
dados permite os seguintes recursos:
a. Os programas de aplicao definem apenas os campos que sero utilizados
independente da estrutura interna dos arquivos
b. Quando h incluso de novos campos no arquivo, ser feita manuteno apenas nos
programas que utilizam esses campos, no sendo necessrio mexer nos demais
programas. Obs.: Nos sistemas tradicionais este tipo de operao requer a alterao
no lay-out de todos os programas do sistema que utilizam o arquivo.
g) Manuteno da Integridade - Consiste em impedir que um determinado cdigo ou chave em
uma tabela no tenha correspondncia em outra tabela. Ex. Um cdigo de uma determinada
disciplina na tabela Histrico Escolar sem a sua descrio na tabela Disciplina.
2. BANCO DE DADOS

Todos ns sabemos existirem gigantescas bases de dados gerenciando nossas vidas. De fato
sabemos que nossa conta bancria faz parte de uma coleo imensa de contas bancrias de nosso
banco. Nosso Ttulo Eleitoral ou nosso Cadastro de Pessoa Fsica, certamente esto armazenados em
Bancos de Dados colossais. Sabemos tambm que quando sacamos dinheiro no Caixa Eletrnico de
nosso banco, nosso saldo e as movimentaes existentes em nossa conta bancria j esto nossa
disposio.
Nestas situaes sabemos que existe uma necessidade em se realizar o armazenamento de
uma srie de informaes que no se encontram efetivamente isoladas umas das outras, ou seja,
existe uma ampla gama de dados que se referem a relacionamentos existentes entre as informaes
a serem manipuladas.
Estes Bancos de Dados, alm de manterem todo este volume de dados organizado, tambm
devem permitir atualizaes, incluses e excluses do volume de dados, sem nunca perder a
consistncia. E no podemos esquecer que na maioria das vezes estaremos lidando com acessos
concorrentes a vrias tabelas de nosso banco de dados, algumas vezes com mais de um acesso ao
mesmo registro de uma mesma tabela!





10
O fato de montarmos uma Mala Direta em um micro PC-XT com um drive j faz de ns um
autor de um Banco de Dados?
Claro que no! Um Banco de Dados antes de mais nada uma coleo logicamente coerente
de dados com determinada significao intrnseca. Em outras palavras um arquivo contendo uma
srie de dados de um cliente, um arquivo com dados aleatoriamente gerados e dois arquivos padro
dbf (dBase) que tem uma relao definida entre ambos, no pode ser considerada uma Base de
Dados Real.
Um Banco de Dados contm os dados dispostos numa ordem pr-determinada em funo de
um projeto de sistema, sempre para um propsito muito bem definido.
Um Banco de Dados representar sempre aspectos do Mundo Real. Assim sendo uma Base
de Dados (ou Banco de Dados, ou ainda BD) uma fonte de onde poderemos extrair uma vasta gama
de informaes derivadas, que possui um nvel de interao com eventos como o Mundo Real que
representa. A forma mais comum de interao Usurio e Banco de Dados, d-se atravs de sistemas
especficos que por sua vez acessam o volume de informaes geralmente atravs da linguagem SQL.
Os Administradores de Banco de Dados (DBA) so responsveis pelo controle ao acesso aos dados e
pela coordenao da utilizao do BD. J os projetistas de Banco de Dados (DBP) so analistas que
identificam os dados a serem armazenados em um Banco de Dados e pela forma como estes sero
representados.
Os Analistas e Programadores de Desenvolvimento, criam sistemas que acessam os dados da
forma necessria ao Usurio Final, que aquele que interage diretamente com o Banco de Dados.

3. SGBD x GA

Um SGBD - Sistema de Gerenciamento de Banco de Dados uma coleo de programas que
permitem ao usurio definir, construir e manipular Bases de Dados para as mais diversas finalidades.
Um conceito que dever ficar bastante claro inicialmente o que envolve a separao clara
entre os Gerenciadores de Base de Dados dos Gerenciadores de Arquivo.
Sistemas baseados em "Banco de Dados" baseados em Btrieve e dBase (Fox e Clipper), podem
no mximo simular as caractersticas tpicas de um ambiente de Banco de Dados. As linguagens
Delphi (utiliza opcionalmente o padro dBase) e o VB (que utiliza o Access), recomendam a utilizao
de Banco de Dados reais, porm utilizam queles "Banco de Dados" que possuem algumas




11
caractersticas de Bancos de Dados, mas possuem caractersticas tpicas de Gerenciadores de
Arquivo.
Vamos definir algumas regras bsicas e claras para um sistema de manipulao de dados ser
considerado um SGBD. Fica implcito que se ao menos uma das caractersticas abaixo no estiver
presente no nosso "candidato" a SGBD, este poder ser um GA (Gerenciador de Arquivo) de altssima
qualidade, "quase" um SGBD, mas no um SGBD.
a) Regra 1: Auto-Conteno - Um SGBD no contm apenas os dados em si, mas armazena
completamente toda a descrio dos dados, seus relacionamentos e formas de acesso.
Normalmente esta regra chamada de Meta-Base de Dados. Em um GA, em algum momento
ao menos, os programas aplicativos declaram estruturas (algo que ocorre tipicamente em C,
COBOL e BASIC), ou geram os relacionamentos entre os arquivos (tpicos do ambiente xBase).
Por exemplo, quando voc obrigado a definir a forma do registro em seu programa, voc no
est lidando com um SGBD.
b) Regra 2: Independncia dos Dados - Quando as aplicaes estiverem realmente imunes a
mudanas na estrutura de armazenamento ou na estratgia de acesso aos dados, podemos dizer
que esta regra foi atingida. Portanto, nenhuma definio dos dados dever estar contida nos
programas da aplicao. Quando voc resolve criar uma nova forma de acesso, um novo ndice,
se precisar alterar o cdigo de seu aplicativo, voc no est lidando com um SGBD.
c) Regra 3: Abstrao dos Dados - Em um SGBD real fornecida ao usurio somente uma
representao conceitual dos dados, o que no inclui maiores detalhes sobre sua forma de
armazenamento real. O chamado Modelo de Dados um tipo de abstrao utilizada para
fornecer esta representao conceitual. Neste modelo, um esquema das tabelas, seus
relacionamentos e suas chaves de acesso so exibidas ao usurio, porm nada afirmado sobre
a criao dos ndices, ou como sero mantidos, ou qual a relao existente entre as tabelas que
dever ser mantida ntegra. Assim se voc desejar inserir um pedido em um cliente inexistente
e esta entrada no for automaticamente rejeitada, voc no est lidando com um SGBD.
d) Regra 4: Vises - Um SGBD deve permitir que cada usurio visualize os dados de forma diferente
daquela existente previamente no Banco de Dados. Uma viso consiste de um subconjunto de
dados do Banco de Dados, necessariamente derivados dos existentes no Banco de Dados, porm
estes no devero estar explicitamente armazenados. Portanto, toda vez que voc obrigado a
replicar uma estrutura, para fins de acesso de forma diferenciada por outros aplicativos, voc
no est lidando com um SGBD.




12
e) Regra 5: Transaes - Um SGBD deve gerenciar completamente a integridade referencial
definida em seu esquema, sem precisar em tempo algum, do auxlio do programa aplicativo.
Desta forma exige-se que o banco de dados tenha ao menos uma instruo que permita a
gravao de uma srie modificaes simultneas e uma instruo capaz de cancelar um srie
modificaes. Por exemplo, imaginemos que estejamos cadastrando um pedido para um cliente,
que este deseje reservar 5 itens de nosso estoque, que esto disponveis e portanto so
reservados, porm existe um bloqueio financeiro (duplicatas em atraso) que impede a venda. A
transao dever ser desfeita com apenas uma instruo ao Banco de Dados, sem qualquer
modificaes suplementares nos dados. Caso voc se obrigue a corrigir as reservas, atravs de
acessos completares, voc no est lidando com um SGBD.
f) Regra 6: Acesso Automtico - Em um GA uma situao tpica o chamado Dead-Lock, o abrao
mortal. Esta situao indesejvel pode ocorrer toda vez que um usurio travou um registro em
uma tabela e seu prximo passo ser travar um registro em uma tabela relacionada primeira,
porm se este registro estiver previamente travado por outro usurio, o primeiro usurio ficar
paralisado, pois, estar esperando o segundo usurio liberar o registro em uso, para que ento
possa trav-lo e prosseguir sua tarefa. Se por hiptese o segundo usurio necessitar travar o
registro travado pelo primeiro usurio (!), afirmamos que ocorreu um abrao mortal, pois cada
usurio travou um registro e precisa travar um outro, justamente o registro anteriormente
travado pelo outro! Imaginemos um caso onde o responsvel pelos pedidos acabou de travar o
Registro Item de Pedido, e, necessita travar um registro no Cadastro de Produtos, para indicar
uma nova reserva. Se concomitantemente estiver sendo realizada uma tarefa de atualizao de
pendncias na Tabela de Itens, e para tanto, previamente este segundo usurio travou a Tabela
de Produtos, temos a ocorrncia do abrao mortal. Se a responsabilidade de evitar esta
ocorrncia for responsabilidade da aplicao, voc no est lidando com um SGBD.
Um SGBD deve obedecer INTEGRALMENTE as seis regras acima. Em caso contrrio estaremos
diante de um GA ou de um "quase" SGBD.
Atualmente, existe uma tendncia de mercado em se dizer que qualquer problema ser
resolvido, caso a empresa adquira um Banco de Dados. Naturalmente, em um ambiente com acesso
constante ao Banco de Dados (acesso concorrente, obviamente), onde a segurana seja de vital
importncia e que o desempenho da aplicao escrita estiver comprometendo a empresa,
considerando-se logicamente uma aplicao bem escrita, sem dvida a aquisio de um Banco de
Dados poder ser o primeiro passo na soluo do problema.




13

Analogamente ao que ocorreu com o aparecimento das primeiras linguagens de programao
voltadas ao Windows, onde estas foram apresentadas como capazes de alavancar os negcios da
empresa, e no geral causaram mais frustao do que soluo, a aquisio do Banco de Dados, pode
gerar o mesmo tipo de problema.
fundamental que a empresa candidata a utilizar um Banco de Dados, normatize-se
totalmente, pois solues quebra galho, tpicas do ambiente que dispe de um Gerenciador de
Arquivo, tendem a ser impossveis em um ambiente estruturado sobre o Banco de Dados. Portanto,
sob pena de se realizar um grande investimento, e no se colher fruto algum, muito conveniente,
que a empresa antes de adquirir um Banco de Dados, passe por um processo de adaptao,
preferencialmente contando com pessoal especializado, geralmente consultores, que no tenham
qualquer ligao com fabricantes de Bancos de Dados.
4. CARACTERSTICAS GERAIS DE UM SGBD


Os SGBD tem sete caractersticas operacionais elementares sempre observadas, que
passaremos a listar:
a) Caracterstica 1: Controle de Redundncias - A redundncia consiste no armazenamento
de uma mesma informao em locais diferentes, provocando inconsistncias. Em um
Banco de Dados as informaes s se encontram armazenadas em um nico local, no
existindo duplicao descontrolada dos dados. Quando existem replicaes dos dados,
estas so decorrentes do processo de armazenagem tpica do ambiente Cliente-Servidor,
totalmente sob controle do Banco de Dados.
b) Caracterstica 2: Compartilhamento dos Dados - O SGBD deve incluir software de
controle de concorrncia ao acesso dos dados, garantindo em qualquer tipo de situao
a escrita/leitura de dados sem erros.
c) Caracterstica 3: Controle de Acesso - O SGDB deve dispor de recursos que possibilitem
selecionar a autoridade de cada usurio. Assim um usurio poder realizar qualquer tipo
de acesso, outros podero ler alguns dados e atualizar outros e outros ainda podero
somente acessar um conjunto restrito de dados para escrita e leitura.




14
d) Caracterstica 4: Interfaceamento - Um Banco de Dados dever disponibilizar formas de
acesso grfico, em linguagem natural, em SQL ou ainda via menus de acesso, no sendo
uma "caixa-preta" somente sendo passvel de ser acessada por aplicaes.
e) Caracterstica 5: Esquematizao - Um Banco de Dados dever fornecer mecanismos que
possibilitem a compreenso do relacionamento existentes entre as tabelas e de sua
eventual manuteno.
f) Caracterstica 6: Controle de Integridade -Um Banco de Dados dever impedir que
aplicaes ou acessos pelas interfaces possam comprometer a integridade dos dados.
g) Caracterstica 7: Backups - O SGBD dever apresentar facilidade para recuperar falhas de
hardware e software, atravs da existncia de arquivos de "pr-imagem" ou de outros
recursos automticos, exigindo minimamente a interveno de pessoal tcnico.
Existe a possibilidade de encontramos Bancos de Dados que no satisfaam completamente
todas as caractersticas acima, o que no o invlida como Banco de Dados. Na prtica podemos
encontrar situaes onde a primeira caracterstica no seja importante, pois podemos ter o Banco
de Dados baseado totalmente em um nico servidor, e as redundncias podem ser aceitas em
algumas situaes sob controle da aplicao (algo no muito recomendado, mas passvel de
aceitao, em situaes onde a existncia do nome do cliente em um arquivo contendo duplicatas
emitidas, possibilita o acesso a apenas uma tabela sem relacionamentos, e sabe-se de antemo que
uma duplicata depois de emitida, no pode ter seu cliente alterado).
A segunda caracterstica (Compartilhamento dos Dados) pode ser desconsiderada
principalmente em ambiente de desenvolvimento, ou ainda em aplicaes remotas.
O Controle de Acesso pode ser descartado em pequenas empresas, sendo que o aplicativo
em questo, mais o software de rede, podem facilmente se incumbir desta caracterstica, no caso de
pequenas empresas, com reduzido nmero de pessoas na rea operacional.
O Interfaceamento e a Esquematizao, so caractersticas sempre disponveis, o que varia
neste caso qualidade destes componentes, que vai desde o sofrvel at o estado da arte. muito
conveniente que esta caracterstica seja muito boa em um Banco de Dados, onde estiverem em
atuao mais de um Administrador de Banco de Dados e tivermos um nmero relativamente alto de
sistemas desenvolvidos ou em desenvolvimento neste ambiente.
De fato, quanto maior o nmero de pessoas envolvidas no desenvolvimento de aplicaes e
gerenciamento do Banco de Dados, mais importante tornam-se estas duas caractersticas, pois cada




15
novo sistema desenvolvido precisar sempre estar adequado ao Banco de Dados da Empresa e
aderente aos padres de acesso utilizados nos sistemas concorrentes.
As interfaces ISQL e WinSQL devem deixar muito claro ao estudante como uma interface
pobre (no caso a existente no ISQL) perde muito, quando comparada a uma interface mais recursiva.
A esquematizao existente no Banco de Dados muito melhor do que aquela mantida em
alguma pasta, em algum arquivo do CPD, que sempre est um pouquinho desatualizada.
O Controle de Integridade, outra caracterstica sempre presente nos Bancos de Dados, mas
existem diferenas quando da implementao desta caracterstica. Assim, comum encontrarmos
Bancos de Dados que suportam determinado acesso, enquanto outros no dispe de recurso
equivalente.
O Backup em tempo de execuo, outra caracterstica sempre disponvel, porm temos
aplicaes que invariavelmente so comprometidas por falhas de hardware, e outras, que o mesmo
tipo de falha no causa perda alguma de dados ou de integridade. Novamente, cada Banco de Dados
tem esta caracterstica melhor ou pior implementada, cabendo ao Administrador de Banco de Dados
escolher aquele que lhe oferecer mais segurana.
Devemos ressaltar ainda, que podemos ter um Banco de Dados Modelo A, que respeite
integralmente as regras bsicas e disponha de todas as caractersticas apresentadas, enquanto um
Modelo B que apesar de respeitar as regras bsicas, no suporte uma ou outra caracterstica
desejvel, mas tenha um desempenho excelente, enquanto o Modelo A seja apenas razovel no
quesito desempenho, nos levar seguramente a escolher o Modelo B como sendo o ganhador para
nossa instalao!
Isto ocorre pois, na prtica, todo usurio deseja um tempo de resposta muito pequeno. O
chamado prazo de entrega muito comum em Bancos de Dados operando nos limites de sua
capacidade, ou nos casos onde o hardware est muito desatualizado, fonte de inmeros problemas
para o pessoal de informtica. Neste caso melhor abrirmos mo de uma Interface Amigvel, de um
Gerencialmente Automtico de Backups ou ainda de outras caractersticas que no julgarmos
fundamentais, para nos livrarmos do problema tpico de ambiente extremamente comprometido,
por m performance do Banco de Dados.
A escolha do Banco de Dados da empresa, portanto uma deciso muito delicada, na medida
em que est ir acarretar troca de aplicativos e troca de hardware. Os investimentos diretamente
aplicados no Banco de Dados, costumam ser infinitamente menores do que aqueles a serem
aplicados na empresa, visando sua perfeita adequao ao novo SGBD. Esta deciso, sempre que




16
possvel, deve ser tomada por especialistas em Banco de Dados, com profundos conhecimentos de
Anlise de Sistemas, de Banco de Dados e de Software de Gerenciamento de Bases de Dados, de
forma a evitar que a empresa escolha um Banco de Dados inadequado aos seus propsitos, e que
pouco tempo depois, seja obrigada a perder todos investimento realizado em Software e Hardware.

5. ARQUITETURA DE UM SGBD

5.1. Estrutura


Podemos dizer que o Banco de Dados tem um Nvel Interno, onde descrita a estrutura de
armazenamento fsico dos dados, um Nvel Intermedirio, onde temos a descrio lgica dos dados
e um Nvel Externo onde so descritas as vises para grupos de usurios.
No podemos deixar de lembrar ainda que o Banco de Dados garante a Independncia Lgica
e Fsica dos Dados, portanto podemos alterar o esquema conceitual dos dados, sem alterar as vises
dos usurios ou mesmo alterar o esquema interno, sem contudo alterar seu esquema conceitual.

5.2. Modelos de Dados


O Modelo de Dados basicamente um conjunto de conceitos utilizados para descrever um
Banco de Dados. No existe uma nica forma de representao deste modelo, porm qualquer forma
que permita a correta compreenso das estruturas de dados compreendidas no Banco de Dados,
pode ser considerada adequada. Vamos descrever sucintamente este modelo, pois estes sero
objetos de outras disciplinas:
a) Modelo Orientado ao Registro: So modelos que representam esquematicamente as
estruturas das tabelas de forma bastante prxima a existente fisicamente. Basicamente
so apresentados os registros de cada tabela (inclusive seus campos) e seus
relacionamentos elementares. O Modelo Relacional, o Modelo de Rede e o Hierrquico
so exemplos deste tipo de representao.
b) Modelo Semntico: So modelos onde existe uma representao explcita das entidades
e relacionamentos. O Modelo Entidade-Relacionamento e o Funcional, so exemplos
deste tipo de abordagem.
c) Modelo Orientado ao Objeto: So modelos que procuram representar as informaes
atravs dos conceitos tpicos da Programao Orientada ao Objeto, utilizando o conceito




17
de Classes que iro conter os objetos. Citamos os Modelos O2 e o de Representao de
Objetos como exemplos tpicos desta abordagem.
O conceito de instncia, sempre muito presente, poderia ser definido como sendo o
conjunto de dados que definem claramente um Banco de Dados em determinado instante.
Devemos entender ento o Banco de Dados como sendo no apenas um conjunto de dados
digitados, mas tambm todo o esquema e regras armazenada e controladas pelo SGBD.
Em outras palavras, podemos dizer que os SGBD, vieram para eliminar todo o trabalho que
anteriormente um programador de aplicao realizava controlando o acesso, integridade e
redundncia dos dados.
6. NORMALIZAO DE DADOS

Consiste em definir o formato lgico adequado para as estruturas de dados identificados
no projeto lgico do sistema, com o objetivo de minimizar o espao utilizado pelos dados e
garantir a integridade e confiabilidade das informaes.
A normalizao feita, atravs da anlise dos dados que compem as estruturas utilizando
o conceito chamado "Formas Normais (FN)". As FN so conjuntos de restries nos quais os dados
devem satisfaz-las. Exemplo, pode-se dizer que a estrutura est na primeira forma normal (1FN),
se os dados que a compem satisfizerem as restries definidas para esta etapa.
A normalizao completa dos dados feita, seguindo as restries das quatro formas
normais existentes, sendo que a passagem de uma FN para outra feita tendo como base o
resultado obtido na etapa anterior, ou seja, na FN anterior.
Para realizar a normalizao dos dados, primordial que seja definido um campo chave
para a estrutura, campo este que permite ir identificar os demais campos da estrutura. Formas
Normais existentes:
6.1 - Primeira Forma Normal (1FN)
Consiste em retirar da estrutura os elementos repetitivos, ou seja, aqueles dados que podem
compor uma estrutura de vetor. Podemos afirmar que uma estrutura est normalizada na 1FN, se
no possuir elementos repetitivos.
Exemplo:
Estrutura original:
Arquivo de Notas Fiscais




18
(Num. NF, Srie, Data emisso, Cod. do Cliente, Nome do cliente, Endereo do cliente, CGC do
cliente, Relao das mercadorias vendidas (onde para cada mercadoria temos: Cdigo da
Mercadoria, Descrio da Mercadoria, Quantidade vendida, Preo de venda e Total da venda
desta mercadoria) e Total Geral da Nota)

Analisando a estrutura acima, observamos que existem vrias mercadorias em uma nica Nota
Fiscal, sendo portanto elementos repetitivos que devero ser retirados.
Estrutura na primeira forma normal (1FN):
Arquivo de Notas Fiscais
(Num. NF, Srie, Data emisso, Cdigo do Cliente, Nome Cliente, Endereo do cliente, CGC do
cliente e Total Geral da Nota)
Arquivo de Vendas
(Num. NF, Cdigo da Mercadoria, Descrio da Mercadoria, Quantidade vendida, Preo de
venda e Total da venda desta mercadoria)
Obs. Os campos sublinhados identificam as chaves das estruturas.
Como resultado desta etapa ocorre um desdobramento dos dados em duas estruturas, a saber:
a) Primeira estrutura (Arquivo de Notas Fiscais): Dados que compem a estrutura original,
excluindo os elementos repetitivos.
b) Segundo estrutura (Arquivo de Vendas): Dados que compem os elementos repetitivos da
estrutura original, tendo como chave o campo chave da estrutura original (Num. NF) e o
campo chave da estrutura de repetio (Cdigo da Mercadoria).

6.2 - Segunda Forma Normal (2FN)
Consiste em retirar das estruturas que possuem chaves compostas (campo chave sendo
formado por mais de um campo), os elementos que so funcionalmente dependente de parte da
chave. Podemos afirmar que uma estrutura est na 2FN, se ela estiver na 1FN e no possuir campos
que so funcionalmente dependente de parte da chave. Exemplo:
Estrutura na primeira forma normal (1FN):
Arquivo de Notas Fiscais
(Num. NF, Srie, Data emisso, Cdigo do Cliente, Nome do cliente, Endereo do cliente, CGC
do cliente e Total Geral da Nota)
Arquivo de Vendas




19
(Num. NF, Cdigo da Mercadoria, Descrio da Mercadoria, Quantidade vendida, Preo de
venda e Total da venda desta mercadoria)
Estrutura na segunda forma normal (2FN):
Arquivo de Notas Fiscais
(Num. NF, Srie, Data emisso, Cdigo do Cliente, Nome do cliente, Endereo do cliente, CGC
do cliente e Total Geral da Nota)

Arquivo de Vendas
(Num. NF, Cdigo da Mercadoria, Quantidade vendida e Total da venda desta mercadoria)

Arquivo de Mercadorias
(Cdigo da Mercadoria, Descrio da Mercadoria, Preo de venda)
Como resultado desta etapa, houve um desdobramento do arquivo de Vendas (o arquivo de
Notas Fiscais, no foi alterado, por no possuir chave composta) em duas estruturas a saber:
a) Primeira estrutura (Arquivo de Vendas): Contm os elementos originais, sendo excludos os
dados que so dependentes apenas do campo Cdigo da Mercadoria.
b) Segundo estrutura (Arquivo de Mercadorias): Contm os elementos que so identificados
apenas pelo Cdigo da Mercadoria, ou seja, independentemente da Nota Fiscal, a descrio
e o preo de venda sero constantes.
6.4 - Terceira Forma Normal (3FN)

Consiste em retirar das estruturas os campos que so funcionalmente dependentes de outros
campos que no so chaves. Podemos afirmar que uma estrutura est na 3FN, se ela estiver na 2FN
e no possuir campos dependentes de outros campos no chaves. Exemplo:
Estrutura na segunda forma normal (2FN):
Arquivo de Notas Fiscais
(Num. NF, Srie, Data emisso, Cdigo do Cliente, Nome do cliente, Endereo do cliente, CGC
do cliente e Total Geral da Nota)
Arquivo de Vendas
(Num. NF, Cdigo da Mercadoria, Quantidade vendida e Total da venda desta mercadoria)
Arquivo de Mercadorias
(Cdigo da Mercadoria, Descrio da Mercadoria, Preo de venda)

Estrutura na terceira forma normal (3FN):
Arquivo de Notas Fiscais
(Num. NF, Srie, Data emisso, Cdigo do Cliente e Total Geral da Nota)




20
Arquivo de Vendas
(Num. NF, Cdigo da Mercadoria, Quantidade vendida e Total da venda desta mercadoria)
Arquivo de Mercadorias
(Cdigo da Mercadoria, Descrio da Mercadoria, Preo de venda)
Arquivo de Clientes
(Cdigo do Cliente, Nome do cliente, Endereo do cliente e CGC do cliente)
Como resultado desta etapa, houve um desdobramento do arquivo de Notas Fiscais, por ser o
nico que possua campos que no eram dependentes da chave principal (Num. NF), uma vez que
independente da Nota Fiscal, o Nome, Endereo e CGC do cliente so inalterados. Este procedimento
permite evitar inconsistncia nos dados dos arquivos e economizar espao por eliminar o
armazenamento frequente e repetidas vezes destes dados. A cada nota fiscal comprada pelo cliente,
haver o armazenamento destes dados e poder ocorrer divergncia entre eles.
As estruturas alteradas foram pelos motivos, a saber:
a) Primeira estrutura (Arquivo de Notas Fiscais): Contm os elementos originais, sendo excludo
os dados que so dependentes apenas do campo Cdigo do Cliente (informaes referentes
ao cliente).
b) Segundo estrutura (Arquivo de Clientes): Contm os elementos que so identificados apenas
pelo Cdigo do Cliente, ou seja, independente da Nota Fiscal, o Nome, Endereo e CGC dos
clientes sero constantes.
Aps a normalizao, as estruturas dos dados esto projetadas para eliminar as inconsistncias
e redundncias dos dados, eliminando desta forma qualquer problema de atualizao e
operacionalizao do sistema. A verso final dos dados poder sofrer alguma alterao, para atender
as necessidades especficas do sistema, a critrio do analista de desenvolvimento durante o projeto
fsico do sistema.
7. MODELO DE ENTEDIDADE E RELACIONAMENTO (MER)

7.1 Definio

Consiste em mapear o mundo real do sistema em um modelo grfico que ir representar o
modelo e o relacionamento existente entre os dados. Este modelo foi desenvolvido a fim de facilitar
o projeto de banco de dados permitindo a especificao de um esquema que representa a estrutura
lgica global do Banco de Dados.





21
7.1.1 Entidade

Identifica o objeto de interesse do sistema e tem "vida" prpria, ou seja, a representao
abstrata de um objeto do mundo real sobre o qual desejamos guardar informaes.
Exemplo: Clientes, Fornecedores, Alunos, Funcionrios, Departamentos, etc.
No so entidades:
a) Entidade com apenas 01 elemento;
b) Operaes do sistema;
c) Sadas do sistema;
d) Pessoas que realizam trabalhos (usurios do sistema);
e) Cargos de direo
Entender determinado problema nem sempre uma tarefa fcil, principalmente se voc no
est familiarizado com a rea de atuao de seu cliente. Antes da implementao em um SGBD,
precisamos de uma descrio formal da estrutura de um banco de dados, de forma independente do
SGBD. Essa descrio formal chamada modelo conceitual. Costumamos representar um modelo
conceitual atravs da abordagem entidade relacionamento (ER). Nesta abordagem construmos um
diagrama, chamado diagrama entidade-relacionamento. Observe abaixo o diagrama que originou as
tabelas Clientes e Telefones:

Entidade pode ser entendida como uma situao ou algo da realidade, modelada onde
deseja-se manter informaes no banco de dados (BD). Por exemplo, em um sistema escolar,
algumas entidades podem ser os alunos, professores, horrio, disciplinas e avaliaes. Note que uma
entidade pode representar tanto objetos concretos (alunos), quanto objetos abstratos (horrio). A
entidade forte representada por um retngulo e a entidade fraca por dois retngulos, um dentro
do outro, onde contm o nome da entidade. Observe o exemplo abaixo.

Entidade Forte Entidade Fraca




22



A entidade ALUNO representa todos os estudantes sobre as quais se deseja manter
informaes no BD. Quando necessrio especificar um objeto particular (para o exemplo,
determinado estudante) usa-se o termo ocorrncia de entidade.
Relacionamento um conjunto de associaes entre entidades. O relacionamento
representado por um losango (que estudaremos mais adiante). Esse losango ligado por linhas aos
retngulos que representam as entidades participantes do relacionamento. O exemplo abaixo possui
duas entidades, MDICO e PACIENTE, e um relacionamento chamado CONSULTA.

O modelo acima informa que o BD mantm informaes sobre mdicos, pacientes, alm de
um conjunto de associaes (consulta), cada uma ligando um mdico a um paciente. Quando
necessrio especificar um relacionamento particular (para o exemplo, determinada consulta) usa-se
o termo ocorrncia do relacionamento. Uma ocorrncia de consulta envolve a ocorrncia de
determinado mdico e a ocorrncia de determinado paciente.

7.1.2 Atributo

Informaes que desejamos guardar sobre a instncia de entidade.
Exemplo: Nome do aluno, Nmero da turma, Endereo do fornecedor, Sexo do funcionrio,
etc.
7.1.3 Domnio do Atributo

Universo de valores que um atributo pode armazenar.
Exemplos:
a) Conjunto de valores do atributo Sexo do funcionrio: M ou F;
b) Conjunto de valores do atributo Nome do aluno: 40 caracteres alfanumricos.
c) Conjunto de valores do atributo salrio: inteiro maior que 5000

ALUNO




23
7.2 - Representao Grfica



7.2.1 Relacionamento

Representa a associao entre os elementos do conjunto de uma entidade com outra
entidade.
Exemplo: O Joo est matriculado na disciplina de Banco de Dados. Onde:
a) Joo: Elemento do conjunto de valores do atributo Nome do aluno da entidade Aluno;
b) Banco de Dados: Elemento do conjunto de valores do atributo Nome da disciplina da
entidade Disciplina;
c) Matriculado: Ligao existente entre um aluno e uma disciplina.


Um relacionamento pode envolver ocorrncias de uma mesma entidade. Neste caso,
estamos diante de um auto relacionamento. Observe o exemplo:

CASAMENTO um relacionamento que envolve duas ocorrncias da entidade PESSOA. Para
facilitar o entendimento, em geral costumamos identificar o papel de cada entidade no
relacionamento (para o exemplo, marido e esposa).


Atributo


Aluno
Matriculado

Disciplina
Relacionamento Entidade




24

7.3 - Cardinalidade de Relacionamentos
Cardinalidade do relacionamento.
Observe o modelo abaixo:

Estamos diante de um relacionamento (possui) entre as entidades EMPREGADO e
DEPENDENTE. Considere as seguintes questes:
a) Um empregado pode no ter dependentes?
b) Um dependente pode ter mais de um empregado associado ?
c) Determinado empregado pode possuir mais de um dependente?
d) Pode existir dependente sem algum empregado associado?
Na realidade, as respostas desses questionamentos dependem do problema sendo
modelado. Entretanto, para que possamos expressar essas ideias no modelo, necessrio definir
uma propriedade importante do relacionamento - sua cardinalidade.
A cardinalidade um nmero que expressa o comportamento (nmero de ocorrncias) de
determinada entidade associada a uma ocorrncia da entidade em questo atravs do
relacionamento.
Existem dois tipos de cardinalidade: mnima e mxima. A cardinalidade mxima, expressa o
nmero mximo de ocorrncias de determinada entidade, associada a uma ocorrncia da entidade
em questo, atravs do relacionamento. A cardinalidade mnima, expressa o nmero mnimo de
ocorrncias de determinada entidade associada a uma ocorrncia da entidade em questo atravs
do relacionamento. Usaremos a seguinte conveno para expressar a cardinalidade:


Observe as cardinalidades mnima e mxima representadas no modelo abaixo:

Nmero (Mnimo, Mximo)





25
Para fazermos a leitura do modelo, partimos de determinada entidade e a cardinalidade
correspondente a essa entidade representada no lado oposto. Em nosso exemplo, a cardinalidade
(0:N) faz referncia a EMPREGADO, j a cardinalidade (1:1), faz referncia a DEPENDENTE. Isso
significa que:
a) Uma ocorrncia de empregado pode no estar associada a uma ocorrncia de dependente
ou pode estar associada a vrias ocorrncias dele (determinado empregado pode no possuir
dependentes ou pode possuir vrios);
b) Uma ocorrncia de dependente est associada a apenas uma ocorrncia de empregado
(determinado dependente possui apenas um empregado responsvel).
Observao: Na prtica, para as cardinalidades mximas, costumamos distinguir dois tipos: 1 (um) e
N (cardinalidades maiores que 1). J para a as cardinalidades mnimas, costumamos distinguir dois
tipos: 0 (zero) e 1 (um).
Atributo uma caracterstica relevante associada a cada ocorrncia de entidade ou
Relacionamento. Observe no modelo abaixo a notao utilizada para atributos:

Para deixarmos o modelo de entidade e relacionamentos mais preciso, necessrio que haja
uma forma de distinguir uma ocorrncia da entidade das demais ocorrncias da mesma entidade.
Sendo assim, cada entidade deve possuir um identificador. H vrias formas de identificarmos
entidades. Observe o modelo abaixo:




26

Neste caso, a entidade aluno possui um nico identificador (Matrcula). Em outras palavras,
cada aluno deve possuir uma matrcula diferente.
Existem situaes onde necessrio mais de um atributo para identificar determinada
entidade. Observe:


Representa a frequncia com que existe o relacionamento, que expressa o nmero de
entidades ao qual outra entidade pode estar associada via um relacionamento, que pode ser uma
das seguintes:

7.3.1 Relacionamento 1:1

Exemplo: O Joo casado com a Maria. Onde:
a) Joo: Elemento do conjunto de valores do atributo Nome da entidade Homem.
b) Maria: Elemento do conjunto de valores do atributo Nome da entidade Mulher.
c) Casado: Ligao entre um homem e uma mulher, sendo que um homem pode ser casado
com uma e apenas uma mulher, assim como uma mulher pode ser casada com um e apenas
um homem.




Homem
Casado

Mulher




27
Imagine uma biblioteca onde os livros ficam armazenados em prateleiras. Estas prateleiras
encontram-se organizadas em corredores. Dessa forma, para identificar uma prateleira necessrio
conhecer seu nmero, alm do nmero do corredor correspondente. Observe o modelo abaixo:

Aqui, o identificador da entidade dependente composto do atributo NMERO SEQUNCIA,
alm do empregado ao qual o dependente est relacionado. Neste caso, estamos diante de um
relacionamento identificador. O relacionamento identificador identificado por uma linha mais
densa.
Vimos que o identificador de entidade corresponde a um conjunto de atributos e
relacionamentos cujos valores diferenciam cada ocorrncia de entidade. No caso de
relacionamentos, em geral a identificao ocorre atravs das ocorrncias das entidades que fazem
parte dele. Observe o exemplo:

O modelo mostra que para cada par (analista, projeto) h no mximo um relacionamento
de alocao.


7.3.2 Relacionamento 1:N ou N:1

Exemplo: O Pedro trabalha no Departamento Pessoal. Onde:
a) Pedro: Elemento do conjunto de valores do atributo Nome da entidade Funcionrio.
b) Depart. Pessoal: Elemento do conjunto de valores do atributo Nome do departamento da
entidade Departamento.




28
c) Trabalha: Ligao entre um Funcionrio e um Departamento, onde um funcionrio pode
trabalhar em um e somente um departamento e um departamento pode ter vrios
funcionrios.






7.3.3 Relacionamento N:M

Exemplo: O Antnio est matriculado na disciplina Banco de Dados. Onde:
a) Antnio: Elemento do conjunto de valores do atributo Nome da entidade Aluno.
b) Banco de Dados: Elemento do conjunto de valores do atributo Nome da Disciplina da
entidade Disciplina.
c) Matriculado: Ligao existente entre um aluno e uma disciplina, onde um aluno pode estar
matriculado em vrias disciplinas e cada disciplina pode ter vrios alunos matriculados.







7.4 - Atributos do Relacionamento

Quando um determinado relacionamento possui atributos, tambm conhecido como
relacionamento valorado. Esta situao ocorre apenas em relacionamento N:M.
Exemplo: Pedro trabalha no projeto Alfa 30 horas.
a) Pedro: Elemento do conjunto de valores do atributo Nome da entidade Funcionrio.
b) Alfa: Elemento do conjunto de valores do atributo Nome do Projeto da entidade Projeto.
c) Trabalha: Ligao existente entre um funcionrio e um projeto. Neste caso, este
funcionrio trabalha 30 horas neste projeto, porm este mesmo funcionrio poder trabalhar
outro nmero de horas em outro projeto, assim como outro funcionrio trabalha outro
Funcionrio Trabalha
Departamento
Aluno
Matriculado
Disciplina




29
nmero de horas no mesmo projeto Alfa. Podemos concluir que 30 horas o atributo que
pertence ao Pedro no projeto Alfa


H casos onde pode ser necessrio relacionar ocorrncias de mesmas entidades mais de uma
vez. Por exemplo, em um modelo de consultas mdicas, determinado paciente pode realizar
consultas mais de uma vez com o mesmo mdico.
Neste caso, podemos utilizar um atributo identificador no relacionamento (data/hora).

1:1

7.5 Grau do Relacionamento

Indica o nmero de entidade que se relacionam.
7.5.1 - Relacionamento Binrio
Quando existe o relacionamento entre apenas duas entidades.
Exemplo: Um fornecedor comercializa materiais que so utilizados em diversos projetos.







30


7.5.2 Relacionamento Ternrio

Quando existe o relacionamento entre trs entidades.
Exemplo: Um fornecedor comercializa materiais que so utilizados em projetos especficos.


Exemplos de Relacionamento:
a) O Professor Alberto leciona Estrutura de Dados e o aluno Pedro cursa Linguagem de
Programao.



Utilizado
Fornecedores Materiais
N:M
Projetos
1: N
1: N






31


b) Pedro comprou 1 Kg. de banana do vendedor Manoel


Obs.: Para que haja uma venda, tem que haver um cliente, um produto e um vendedor.

7.6 Dependncia Existencial

Forma outra importante classe de restries. Especificamente, se a existncia da entidade X
depende da existncia da entidade Y, ento diz-se que X existencialmente dependente de Y.
Operacionalmente, isto significa que se Y for removido, ento x tambm ser. A entidade Y
chamada de entidade dominante e X chamada de entidade subordinada.
Exemplo: Conta e Transao (Conta dominante e Transao subordinada)


Venda
Clientes Produtos
1: N
Vendedores
1: N 1:1






32
Uma entidade fraca representada por um duplo retngulo


7.7 Identificador de Entidade

o atributo que a identifica incontestavelmente. Portanto, seu conceito similar ao
conceito de chave primria em processamento de dados convencional.

Um conjunto de entidades fracas no tem chave primria. Porm, necessitamos criar um
identificador que faa a distino de uma determinada entidade fraca associada a entidade forte.

7.8 Esquema Relacional

Aps a elaborao do diagrama E-R precisamos traduzir para um esquema mais adequado a
tarefa de projetos de formatos de registros modelagem de dados.
Para traduzirmos um modele E-R num esquema relacional, existem algumas regras bsicas
com base no tipo de relacionamento entre as entidades.

7.8.1 Relacionamento definido por dois tipos diferentes de entidades

a) 1 x 1 - A chave de qualquer entidade pode ser inserida na outra entidade. Os atributos do
relacionamento, se houver, podem ser colocados normalmente nas entidades envolvidas.
b) 1 x N Inserir a chave primria da entidade 1. A entidade N herda o atributo do
relacionamento.
c) M x N Criar uma Relao de Ligao contendo;
- Chaves primrias das entidades participantes do relacionamento
- Atributos do relacionamento

7.8.2 Relacionamentos definidos por mais de dois tipos de entidades;








33
Independente do tipo de relacionamento, a soluo tambm ser criarmos uma Relao de
Ligao contendo as chaves primrias de todas as entidades mais os atributos do relacionamento.

7.8.3 Traduo de entidades Fracas

Inserir na entidade fraca a chave ao qual ela est subordinada.
7.9 Exerccios

1) Elaborar um diagrama E-R para uma seguradora de automveis
Entidades: Cliente, Aplice, Carro e Acidentes.
Requisitos:
a) Um cliente pode ter vrias aplices (no mnimo uma);
b) Cada aplice somente d cobertura a um carro;
c) Um carro pode ter zero ou n registros de acidentes a ele.
Atributos:
a) Cliente: Nmero, Nome e Endereo;
b) Aplice: Nmero e Valor;
c) Carro: Registro e Marca;
d) Acidente: Data, Hora e Local.

2) Elaborar um diagrama E-R de um consultrio clnico
Entidades: Mdico, Paciente e Exame.
Requisitos:
O banco de dados dever armazenar informaes sobre os vrios exames de um determinado
paciente, com o resultado e o valor pago (pode-se dar desconto para determinados pacientes).
Atributos:
a) Mdico: Nmero, Nome e Especialidade;
b) Paciente: Nmero, Nome, Endereo;
c) Tipo Exame, Aceita Convnio, Requisitos, Valor exame.

3) Elaborar um diagrama para uma Indstria.
Entidades: Peas, Depsitos, Fornecedor, Projeto, Funcionrio e Departamento.
Requisitos:




34
a) Cada Funcionrio pode estar alocado a somente um Departamento;
b) Cada Funcionrio pode pertencer a mais de um Projeto;
c) Um projeto pode utilizar-se de vrios Fornecedores e de vrias Peas;
d) Uma Pea pode ser fornecida por vrios Fornecedores e atender a vrios Projetos;
e) Um Fornecedor pode atender a vrios Projetos e fornecer vrias Peas;
f) Um Depsito pode conter vrias Peas;
g) Deseja-se ter um controle do material utilizado por cada Projeto, identificando inclusive o seu
Fornecedor. Gravar as informaes de data de Incio e Horas Trabalhadas no Projeto.
Atributos:
a) Peas: Nmero, Peso e Cor;
b) Depsito: Nmero e Endereo;
c) Fornecedor: Nmero e Endereo;
d) Projeto: Nmero e Oramento;
e) Funcionrio: Nmero, Salrio e Telefone;
f) Departamento: Nmero e Setor.

4) Projetar um Banco de Dados satisfazendo as seguintes restries e requisitos:
a) Para um Vendedor, armazenar seu cdigo, nome, endereo e comisso;
b) Para um cliente, armazenar o seu cdigo, nome, endereo, faturamento acumulado e limite
de crdito. Alm disso, armazenar o cdigo e o nome do vendedor que o atende. Um
vendedor pode atender muitos clientes, porm um cliente deve ter exatamente um
vendedor;
c) Para uma pea, armazenar seu cdigo, descrio, preo quantidade em estoque e o nmero
do armazm onde a pea est estocada. Uma pea somente pode estar estocada num nico
armazm. Para um armazm, armazenar seu cdigo e endereo;
d) Para um pedido, armazenar seu nmero, data, cdigo, nome e endereo do cliente, que fez
o pedido e o cdigo do vendedor para clculo da comisso. Alm disso, para cada item do
pedido armazenar o cdigo da pea, quantidade e preo cotado. H somente um cliente por
pedido e um vendedor;
e) O preo cotado no pedido pode ser mesmo que o preo corrente no arquivo de peas, mas
no necessariamente.





35
8. INTRODUO AOS TIPOS DE DADOS

O processo de modelagem de um banco de dados consiste em representar situaes do
mundo real atravs de um sistema. razovel imaginar que diversas informaes podem ser
armazenadas em um banco de dados, tais como endereos, imagens, datas, nmeros, moedas,
dentre outras. Conforme descrito anteriormente, todo atributo de uma tabela necessita ter um
domnio ou conjunto de valores aceitveis. Por exemplo, ao definir a data de nascimento de uma
pessoa no desejvel que o sistema permita a insero de um texto neste campo. Em uma coluna
que armazena os salrios dos funcionrios devem-se ter apenas valores numricos e no datas e
horas, por exemplo.
Portanto, toda definio de tabelas passa pela construo dos seus atributos com seus
respectivos tipos de dados ou domnios. Como o MySQL o sistema de banco de dados adotado
nesta apostila a Tabela 1 a seguir apresenta um subconjunto dos possveis tipos de dados a serem
empregados, bem como os tipos de informaes que podem ser armazenados nestas colunas.


TIPO DE DADO FORMATO DESCRIO

Ao inserir uma linha ou registro em uma tabela deve-se informar um valor para cada coluna,
respeitando o tipo de dados definido para aquele atributo. Existem situaes em que o valor a ser
colocado em uma coluna no conhecido no momento da incluso dos dados na tabela. Por
exemplo, se existir uma coluna que armazena a data de nascimento dos funcionrios, esta data em
geral no conhecida no momento da incluso do registro.
Para contornar esta situao existe um valor especial conhecido como NULL que denota o
fato de que a informao no conhecida. No caso da data de nascimento, pode-se utilizar o valor
NULL para os funcionrios que ainda no apresentaram a documentao. possvel definir no
momento da criao da tabela se as colunas aceitam ou no este valor especial. Isto feito atravs
da clusula NOT NULL, que deve ser colocada nas colunas que no aceitaro o NULL, lembrando que




36
por padro qualquer coluna aceita o NULL. importante lembrar que colunas de qualquer tipo
podem receber o valor NULL.

9. DESCRIO DOS COMANDOS PARA DEFINIO DE DADOS

O objetivo desta seo apresentar a sintaxe dos comandos para a criao de bancos de
dados e tabelas, expondo todos os comandos que constituem a linguagem SQL DDL.

9.1 Criando e removendo um banco de dados

Um banco de dados entendido como uma coleo de tabelas. De fato uma forma de se
organizar as informaes dentro do SGBD, isto , cada aplicao pode ter o seu prprio banco de
dados, onde estaro apenas as tabelas que fazem parte daquele problema. A Listagem 1 fornece a
sintaxe do comando para a criao do banco de dados.

CREATE DATABASE nome_do_banco
Listagem 1: Sintaxe do comando CREATE DATABASE

Por conveno, todos os comandos que se referem linguagem SQL sero colocados em
letras maisculas, enquanto os valores que sero informados pelos usurios sero exibidos em
itlico. No exemplo anterior nome_do_banco dever ser substitudo pelo nome do banco que se
deseja criar. Vale ressaltar que este comando pode ser submetido ao SGBD a partir de qualquer
cliente SQL, como o MySQL Query Browser, ou o cliente mysql utilizado a partir de um terminal do
Linux.
Para selecionar um banco de dados deve-se utilizar o comando USE, conforme ilustra a
Listagem 2.

USE nome_do_banco
Listagem 2: Selecionando um banco de dados

Uma vez selecionado o banco e dados, pode-se manipular as tabelas contidas nele, ou at
mesmo criar novas tabelas dentro deste banco de dados.
Para remover um banco de dados e todo o seu contedo, o comando DROP DATABASE deve
ser utilizado. A Listagem 3 fornece a sintaxe deste comando.

DROP DATABASE nome_do_banco
Listagem 3: Removendo um banco de dados e todo seu contedo

O comando anterior remove o banco de dados e todas as tabelas contidas nele, portanto
deve-se agir com prudncia a fim de que no sejam obtidos resultados indesejados.
Este o primeiro passo para a construo de uma base de dados, deve-se apenas substituir
o termo nome_do_banco pela nome do banco desejado.

9.2 Criando e removendo tabelas

Para criar uma tabela preciso primeiro identificar os atributos e seus tipos de dados, bem
como as restries em relao ao valor NULL, isto , se havero colunas com valores indefinidos.
Alm disto, necessrio identificar a chave primria da tabela, que o conjunto de colunas que
referenciam de forma nica cada registro da tabela.




37
Finalmente, para as tabelas que participam de algum relacionamento necessrio
determinar as chaves estrangeiras e as restries que se aplicam sobre elas. Neste caso, o objetivo
da chave estrangeira identificar os registros que participam da relao e impor as regras de
integridade que regem o relacionamento. Por exemplo, em um relacionamento entre funcionrios e
equipes, deve-se garantir que no haver um membro da equipe que no esteja cadastrado na tabela
de funcionrios. Ou em um relacionamento entre pais e filhos, deve-se garantir que no haver um
filho sem um pai.
Para a criao de uma tabela utiliza-se o comando CREATE TABLE, cuja sintaxe bsica est
apresentada na Listagem 4.

CREATE TABLE nome_da_tabela (
Coluna1 TIPO_COLUNA_1,
Coluna2 TIPO_COLUNA_1,
. . .
Coluna N TIPO_COLUNA_N,
PRIMARY KEY (colunas),
[ FOREIGN KEY (colunas) RESTRIES ]
) [ENGINE=tipo];
Listagem 4: Sintaxe do comando CREATE TABLE

Como descrito na listagem anterior para criar uma tabela deve-se especificar o nome de cada
coluna ou atributo que a constitui, seus tipos e a sua chave primria. Nota-se que a chave estrangeira
opcional, portanto aparece entre colchetes ([FOREIGN KEY]). No MySQL possvel escolher o tipo
de tabela a ser criado (ENGINE), que para efeito deste material, no ser utilizado. A explicao dos
tipos de tabelas do MySQL ficam fora do escopo deste material.
O TIPO_COLUNA dever ser substitudo por alguns dos tipos de dados suportados pelo SGBD
utilizado. No caso do MySQL pode-se utilizar os tipos descritos na Tabela 1 ou qualquer outro tipo
de dado suportado por ele. Nas subsees seguintes sero apresentados exemplos da utilizao
deste comando.

9.2.1 Entendendo o conceito de chaves primria

A Listagem 5 fornece os comandos para a criao das tabelas cargo, empresa e equipes, que
seguem a sintaxe apresentada anteriormente.

CREATE TABLE cargos (
codigo integer unsigned NOT NULL auto_increment,
nome char(50) NOT NULL,
PRIMARY KEY (codigo)
);

CREATE TABLE empresa (
codigo integer unsigned NOT NULL auto_increment,
nome char(60) NOT NULL,
cnpj char(20) NOT NULL,
telefone char(20) NOT NULL,
PRIMARY KEY (codigo)
);





38
CREATE TABLE equipes (
codigo integer unsigned NOT NULL auto_increment,
nome char(60) NOT NULL,
PRIMARY KEY (codigo)
) ;
Listagem 5: Comandos para a criao das tabelas cargo, empresa e equipes

No exemplo, todas as colunas foram criadas com a opo NOT NULL, isto , no possvel
informar primria o valor NULL para nenhuma das colunas. Todas as tabelas tm uma coluna cdigo
que a chave da tabela. Isto significa dizer que no h nestas tabelas dois registros com o mesmo
cdigo, caso contrrio no seria possvel encontrar um determinado registro na base de dados devido
ambiguidade. Caso ocorra uma tentativa de inserir dois registros com o mesmo cdigo numrico,
o SGBD emitir uma mensagem de chave duplicada (Duplicate key entry), e inibir a insero do
mesmo. A Figura 1 ilustra a situao onde feita a tentativa de inserir o cargo de pedreiro utilizando
o cdigo idntico ao do cargo de arquiteto. Percebe-se, em destaque na figura, a mensagem de erro
emitida pelo SGBD ao tentar executar a insero atravs do acionamento do boto Apply Changes
(Aplicar alteraes).
Figura 1: Erro na insero de dois cargos com o cdigo 2

Na definio dos cdigos foi utilizado o atributo AUTO_INCREMENT, cuja funo gerar um
nmero sequencial automtico. Isto significa dizer que durante a insero, se o cdigo for omitido
o SGBD criar um cdigo a partir do maior cdigo cadastrado acrescido de um. Ou seja, se o maior
cdigo de cargos o valor dois, a prxima insero de cargos gerar o cdigo trs, e assim
sucessivamente. Isto reduz a possibilidade de erros devido a chaves duplicadas, j que o cdigo ser
gerado automaticamente pelo sistema e nunca se repetir.
Para utilizar o recurso do AUTO_INCREMENT, a coluna deve ser declarada como do tipo
inteiro e dever ser a chave primria da tabela. Caso contrrio, o sistema no permitir a sua criao.
Vale lembrar que no DBDesigner4 a criao da coluna auto incremento feita a partir da seleo do
atributo AI, presente no editor de atributos.

9.2.2 Entendendo o conceito de chave estrangeira





39
As demais tabelas do banco curso apresentam relacionamentos entre elas, obedecendo s
regras de integridade definidas pelo modelo lgico da aplicao. A Listagem 6 contm os comandos
para a criao das tabelas funcionrios, obras e obras_tem_equipes.

CREATE TABLE funcionarios (
cpf char(20) NOT NULL,
Cargos_codigo int(10) unsigned NOT NULL,
nome char(60) NOT NULL,
nascimento date NOT NULL,
telefone char(20) NOT NULL,
PRIMARY KEY (cpf),
FOREIGN KEY (Cargos_codigo) REFERENCES cargos (codigo)
);
CREATE TABLE obras (
codigo int(10) unsigned NOT NULL auto_increment,
Empresa_codigo int(10) unsigned NOT NULL,
nome char(50) NOT NULL,
inicio date NOT NULL,
termino date NOT NULL,
PRIMARY KEY (codigo),
FOREIGN KEY (Empresa_codigo) REFERENCES empresa (codigo) ON DELETE CASCADE ON
UPDATE CASCADE
);

CREATE TABLE obras_tem_equipes (
Obras_codigo int(10) unsigned NOT NULL,
Equipes_codigo int(10) unsigned NOT NULL,
PRIMARY KEY (Obras_codigo,Equipes_codigo),
FOREIGN KEY (Obras_codigo) REFERENCES obras (codigo) ON DELETE CASCADE ON UPDATE
CASCADE,
FOREIGN KEY (Equipes_codigo) REFERENCES equipes (codigo) ON DELETE CASCADE ON UPDATE
CASCADE
);
Listagem 6: Comandos para a criao das tabelas funcionrio, obras e obras_tem_equipes

Percebe-se que nestas tabelas existe alm da chave primria a definio de chaves
estrangeiras, j que estas tabelas participam de relacionamentos. No caso da tabela de funcionrios,
os registros desta tabela esto associados a registros existentes na tabela de cargos. Ou seja, todo
funcionrio tem um cargo, onde esta relao salientada pela coluna Cargos_codigo da tabela de
funcionrios.
Uma chave estrangeira nada mais que a chave primria de uma tabela colocada em outra
tabela para identificar a relao entre elas. Para cri-la deve-se indicar qual o conjunto de colunas
que a compe, bem como a tabela e coluna que esta referncia. No exemplo tm-se FOREIGN KEY
(Cargos_codigo) REFERENCES cargos (codigo). Isto significa dizer que os valores armazenados na
coluna Cargos_codigo da tabela de funcionrios, deve ser um valor contido na coluna cdigo da
tabela de cargos. Desta forma, o SGBD assegura que nenhum funcionrio ter um cargo que no
esteja cadastrado na tabela de cargos. A Figura 2 ilustra uma tentativa de insero de um funcionrio
com um cargo invlido.





40





Figura 2: Erro na insero de funcionrio com cargo inexistente

Percebe-se em destaque na figura que o sistema emitiu uma mensagem de erro indicando
que uma restrio de integridade foi violada (Cannot add or update a child row: a foreign key
contraint fails, em portugus, No possvel adicionar ou alterar o registro: Falha de restrio de
chave estrangeira), e desta forma o comando no executado.
Existe ainda a situao onde uma alterao ou excluso de um cargo pode levar a uma
inconsistncia de dados na tabela de funcionrios. No caso de uma remoo ou modificao de um
cargo para o qual existam funcionrios cadastrados, deve-se garantir que o funcionrio no ficar
com um cargo invlido.
Para isto, foram especificadas as restries de chave estrangeira ON UPDATE CASCADE e ON
DELETE RESTRICT. Isto , quando o cdigo de um cargo for alterado o SGBD propagar
automaticamente a modificao para todos os funcionrios que estejam cadastrados com este cargo
(CASCADE). J no caso da remoo, o sistema no permitir a excluso de cargos que apresentem
funcionrios associados a ele (RESTRICT). Vale ressaltar que a opo CASCADE ou RESTRICT pode ser
aplicada s clusulas UPDATE e DELETE de acordo com a restrio imposta pelo modelo.
Para ilustrar a utilizao das clusulas RESTRICT e CASCADE, considere um cadastro de
funcionrios e os seus dependentes ou filhos. Se o CPF do funcionrio, que a chave primria, for
alterado necessrio alterar o CPF na tabela de filhos, pois do contrrio a relao entre as duas
entidades se perderia, j que o filho estaria associado com um CPF de um funcionrio inexistente.
Desta forma, pode-se inibir a alterao do CPF do pai durante um UPDATE, empregando a clusula
RESTRICT. Ou pode-se possibilitar a alterao automtica do CPF em ambas as tabelas atravs do
CASCADE.
O mesmo raciocnio se aplicaria no momento da excluso de um funcionrio, isto no
comando DELETE. Ao excluir um funcionrio no se pode manter os registros e seus eventuais
dependentes, pois desta forma teramos registros rfos na tabela de dependentes. Portanto, pode-
se inibir a remoo dos funcionrios que tenham filhos com o RESTRICT, ou forar a excluso dos
filhos com a opo CASCADE. Todo este mecanismo visa a manuteno da consistncia das
informaes, que j foi discutida nos captulos anteriores.
Alm disto, uma nica tabela pode conter mais de uma chave estrangeira dependendo de
como esto organizados os relacionamentos entre elas. Isto o que ocorre no caso da tabela
obras_tem_equipes, que se relaciona com as tabelas obras e equipes, simultaneamente. Por isto
apresenta duas chaves estrangeiras, referenciando a chave primria de cada tabela.




41
O grande benefcio das chaves estrangeiras o fato de que o prprio SGBD assegura que as
restries de integridade pertinentes ao modelo sero aplicadas, mesmo que o usurio do banco
desconhea estas regras.

9.2.3 Removendo tabelas

Finalmente, para remover uma tabela utiliza-se o comando DROP TABLE conforme ilustra a
Listagem 7.

DROP TABLE nome_da_tabela
Listagem 7: Comando para a excluso de uma tabela

Ao executar este comando a tabela ser apagada por completo, juntamente com os dados
que por ventura estejam armazenados nela. Por isto, deve-se ter cuidado na utilizao do mesmo
para evitar resultados indesejados.
Outra situao comum no dia a dia da utilizao de um sistema de banco de dados a
necessidade de alterar a estrutura de uma tabela j existente. Por exemplo, supondo uma alterao
no modelo lgico da aplicao de forma que se tenha que armazenar a data de entrada do
funcionrio na empresa, o que no era necessrio anteriormente. Para contemplar esta situao
seria necessria a incluso de uma nova coluna do tipo data tabela de funcionrios, previamente
criada.