Documente Academic
Documente Profesional
Documente Cultură
Banco de Dados
Volume 3
Recife, 2010
Universidade Federal Rural de Pernambuco
Apresentação.................................................................................................................. 4
Dependências Funcionais...............................................................................................41
Anomalias de Atualização...............................................................................................43
O que é Normalização?..................................................................................................45
Considerações Finais..................................................................................................... 68
Conheça a Autora......................................................................................................... 70
Apresentação
Caro(a) cursista,
Seja bem-vindo(a) ao terceiro módulo do curso Banco de Dados!
Neste terceiro módulo, vamos estudar o modelo relacional e todas as suas nuances. O modelo relacional é
o resultado da modelagem lógica do Banco de Dados e é a etapa seguinte a modelagem conceitual.
Dentro deste contexto, estudaremos como tranformar a modelagem conceitual em modelagem lógica,
como otimizar o modelo criado através das regras de normalização e como fazer as checagens de integridade
referencial.
Bons estudos!
Sandra de Albuquerque Siebra
Autora
4
Banco de Dados
Conhecendo o Volume 3
Neste terceiro volume, você irá encontrar o Módulo 3 da disciplina de Banco de
Dados. Para facilitar seus estudos, veja a organização deste segundo módulo.
» O Modelo Relacional.
» As 12 Regras de Codd.
» Transformação do Modelo E-R para o Modelo Relacional.
» Restrições de Integridade.
» Dependências Funcionais.
» Normalização de Dados.
5
Banco de Dados
Capítulo 7
» O Modelo Relacional.
» Restrições de Integridade.
Metas
6
Banco de Dados
O Modelo Relacional foi introduzido por Ted Codd, da IBM Research, em 1970, em
um artigo clássico (Codd, 1970) que imediatamente atraiu a atenção em virtude de sua
simplicidade e base matemática. O modelo usa o conceito de uma relação matemática –
algo como uma tabela de valores – como seu bloco de construção básica e tem sua base
teórica na teoria dos conjuntos.
As primeiras implementações comerciais do modelo relacional tornaram-se
disponíveis no início da década de 80, antes disso, eram utilizados os modelos de redes e
hierárquico (sobre os quais estudamos no Volume 1, capítulo 1).
O modelo relacional tem como objetivos: prover esquemas de fácil utilização;
melhorar a independência lógica e física de dados; prover os usuários com linguagens
de manipulação de BD de alto nível, permitindo o seu uso por usuários não experientes;
otimizar o acesso aos BDs e melhorar a integridade e segurança dos dados.
Comentário
O MR representa os dados do BD como relações1 (tabelas) de nomes únicos. O
conceito de tabelas está intimamente ligado ao conceito de uma relação matemática – de
1
A palavra relação é
utilizada no sentido onde se origina o nome deste modelo. Vamos apresentar, na seção a seguir, cada um dos
de lista ou rol de conceitos relevantes dentro do contexto do modelo relacional.
informações e não no
sentido de associação
ou relacionamento.
Conceitos do Modelo Relacional
Em um ambiente de banco de dados relacional, utilizamos alguns conceitos muito
importantes para a correta implantação e operação de qualquer sistema de banco de
dados. Por exemplo, na terminologia do modelo relacional, cada tabela é chamada relação
e vai possuir um nome único que a identifica; cada linha da tabela é chamada tupla e cada
cabeçalho de coluna é conhecido como atributo (vide Figura 2).
Tabela ou Relação
8
Banco de Dados
poderiam ser armazenados dados como o CPF, o nome e o telefone de cada empregado. A
tabela como um todo representaria os empregados da empresa. Cada coluna representaria
um atributo (ex: a primeira coluna da Tabela 1 é o CPF ). E cada linha da tabela representa os
dados de um empregado. Por exemplo, a primeira linha da Tabela 1 refere-se à empregada
de CPF número 987675456-98, de nome Ana Marques e cujo telefone é 3245-8976.
Comentário
Matematicamente, define-se uma relação como um subconjunto de um produto
cartesiano de uma lista de domínios2. Assim, suponha que D1 denote o domínio do atributo
2
Um domínio contém
A1, D2 denote o domínio do atributo A2 e Dn denote o domínio do atributo N da tabela T1.
os valores possíveis
Qualquer linha da tabela que possui estes atributos é denotada pela tupla3 (d1,d2,...,dn) em para um determinado
que d1, d2 e dn têm como valores possíveis (domínios), respectivamente D1, D2 e Dn. Em atributo da relação.
geral, uma instância de T1 é um subconjunto de D1 X D2 X ... X Dn.
O conjunto de atributos de uma relação é chamado de esquema da relação. O
esquema de uma relação é denotado por : R[A1 D1, ..., An Dn] onde: Comentário
R é o nome da relação; 3
Uma tupla é uma
A1, ..., An é a lista de atributos da relação R e ocorrência particular
de um elemento da
D1, ..., Dn são os domínios de cada um dos atributos da relação R. tabela. Falaremos
sobre esse conceito,
Frequentemente, é utilizada uma notação simplificada em que é omitida a definição em detalheas, mais a
do domínio de cada atributo da relação: R[A1, ..., An]. Por exemplo, o esquema da relação frente.
representada na Tabela 1 seria: Empregado[CPF char4(11), Nome char(50), Telefone
char(9)] ou, na notação simplificada, teríamos Empregado[CPF, Nome, Telefone].
Na criação dos esquemas das relações o nome das relações ou tabelas devem ser Comentário
únicos no banco de dados, devem ser escritos no singular e, de preferência, devem ser
nomes curtos. Se for usado um nome composto, este deve ser separado por um underline 4
O tipo char equivale
(_), por exemplo Pessoa_Fisica ou Pessoa_Juridica. ao tipo string das
linguagens de
O grau de uma relação é o número de atributos que a compõe. Por exemplo, o grau programação, onde
você pode digitar
da relação Empregado[CPF, Nome, Telefone] é três, porque essa relação possui 3 atributos.
letras, números e
Uma particularidade referente à definição de relação é que, nesta definição, não símbolos. Quando
você define um tipo
existe qualquer tipo de ordenação ou de definição de ordenação. Assim, por exemplo, as char, você tem de
duas relações representadas pelas Tabelas 1 e 2 são consideradas idênticas. Afinal, o que especificar o tamanho
mudou de uma tabela para outra foi apenas a ordem em que os valores de preenchimento do que preencherá
o mesmo. Esse tipo
da tabela aparecem.
pode variar de nome
de SGBD para SGBD
mas sempre vai ter um
correspondente.
9
Banco de Dados
Linha (Tupla)
Uma ocorrência, em particular, de dados em uma tabela ocupa uma linha dessa
tabela. Por exemplo, na Tabela 3, os dados de cada um dos empregados que a compõe
ocupam uma linha diferente da tabela. Como existem 4 empregados, a Tabela 3 possui 4
linhas (ou tuplas ou registros). O número de linhas ou tuplas de uma relação é chamado de
cardinalidade da relação. Logo, a cardinalidade da relação expressa na Tabela 3 é quatro.
Cada linha da tabela deve ser única e deve possuir um atributo identificador. No
caso da Tabela 3, esse identificador é o CPF do empregado. O atributo identificador, no
modelo relacional, passa a ser chamado de chave primária (PK) - detalharemos melhor esse
ponto mais a frente.
Outra definição que pode ser dada para linha ou tupla é: um conjunto de pares
(<atributo>,<valor>), em que cada par fornece o valor do mapeamento de um atributo Ai
para um valor Vi, tal que cada valor Vi seja um elemento do domínio Di ou um valor nulo.
Algumas regras para tuplas são: em uma tabela ou relação não devem existir tuplas
ou linhas duplicadas. As linhas de uma tabela não seguem uma ordem específica. Dessa
forma, as tuplas ou linhas abaixo seriam idênticas:
T = <(CPF, 987675456-98), (Nome, Ana Marques), (Telefone, 3245-8976)> e
T = <(Telefone, 3245-8976), (CPF, 987675456-98), (Nome, Ana Marques)>
Coluna (Atributo)
Cada tipo de informação armazenada em uma tabela é uma coluna. Ou seja, cada
10
Banco de Dados
atributo que caracteriza a relação é expresso em uma coluna. Toda coluna de uma tabela
deve possuir um nome pelo qual será referenciada sempre que necessário. Na verdade,
ao criarmos uma tabela definimos, para cada uma de suas colunas, o seu nome (nome do
atributo) e também o seu tipo (numérico, alfabético, data, etc). Por exemplo, CPF, Nome e
Telefone são atributos (colunas ou campos) da Tabela Empregado, expressos na Tabela 3.
Um nome de atributo deve ser único em uma tabela e deve expressar o tipo de
informação que ele representa. E o valor de um atributo não deve poder ser decomposto
em mais de uma coluna.
Domínio do Atributo
Chaves
Comentário
Uma chave5 é um atributo (ou conjunto de atributos) que identifica univocamente
cada entrada de uma relação. Ou seja, por meio de chaves podemos diferenciar as diversas
5
O conceito
de chave está
tuplas pertencentes a uma relação. Como consequência dessa definição, temos que os diretamente ligado
atributos chaves não podem apresentar valores duplicados, nem podem ser nulos. ao de identificador
da entidade ou
relacionamento que foi
NULO - Não devemos confundir o conceito de nulo com espaços em branco ou o número zero, por
estudado no volume
exemplo, que são valores conhecidos. Nulo é a ausência de informação. anterior, quando
foram detalhados os
Uma coluna de preenchimento obrigatório numa tabela deve possuir todos os seus valores não- componentes do MER.
nulos. Se, por exemplo, uma linha da tabela Empregado contiver um nulo na coluna Telefone,
significa que o telefone do empregado correspondente àquela linha é desconhecido. Assim, ou o
telefone não foi informado por algum motivo ou o empregado não possui telefone, de qualquer
forma, a informação está ausente na tabela.
Comentário
Uma definição mais formal para chave seria: seja R um esquema de relação. Se
dissermos que um subconjunto K de atributos de R é uma superchave6 para R, estaremos
6
Superchave é o
conjunto de um ou
considerando restrições para as relações r(R), nas quais não existem duas tuplas distintas
mais atributos que nos
com mesmos valores em todos os atributos de K. Isto é, se as tuplas t1 e t2 fazem parte da permitem identificar
relação r e t1 <> t2, então t1[K] <> t2[K]. de maneira unívoca
uma tupla de uma
Quando há a possibilidade de mais de um atributo (isoladamente) poder ser chave relação.
em uma relação, dizemos que esses atributos são chaves candidatas. Por exemplo, na Tabela
4, CPF e Nome poderiam ser chaves candidatas, porque poderiam ser atributos usados para
localizar uma entrada na tabela.
11
Banco de Dados
Um dos princípios do modelo relacional diz que uma linha de uma tabela deve
sempre poder ser referenciada de forma única. Por isso, entre as chaves candidatas, uma
delas deve ser eleita para ser a principal, a chave primária da tabela (Primary Key ou PK),
aquela que realmente identifica univocamente cada tupla da tabela. No caso, para a Tabela
4, a melhor escolha para chave primária seria o atributo CPF, já que essa informação não se
repetiria, de forma alguma, em dois empregados distintos da tabela.
A escolha da chave primária (PK) da tabela é influenciada pelas necessidades do domíno do mundo
real que está sendo modelado.
Chaves primárias são, geralmente, indicadas na tabela pela sigla PK (Primary Key) e
podem também ser sublinhadas (vide Tabela 4).
As outras chaves candidatas que não forem escolhidas para chave primária, são
chamadas de chaves secundárias. Por exemplo, na Tabela 4, o atributo Nome seria uma
chave secundária.
Muitas vezes, uma tabela não possui, entre seus atributos, um que por si só seja
suficiente para identificar univocamente uma ocorrência. Nesses casos, deve se tentar achar
uma combinação de dois ou mais atributos que tenham a capacidade de se constituir numa
chave primária. Chamamos a essas chaves primárias, formadas pela combinação de vários
atributos, de chaves primárias compostas. Ou seja, uma chave primária composta é aquela
formada por mais de um atributo ou coluna. Geralmente, uma tabela que represente um
relacionamento entre outras duas tabelas (originada de um relacionamento do MER) irá
possuir chaves primárias compostas. Por exemplo, a tabela Alocação (vide Tabela 5), terá
como chaves primárias os atributos CPF (vindo da Tabela Empregado – vide Tabela 6) e
Cod_Projeto (vindo da Tabela Projeto – vide Tabela 7). Isso, porque para descobrir qual a
função de um empregado em um projeto, precisamos dessas duas informações. Nenhum
dos atributos isoladamente poderia fornecer essa informação.
Se mesmo com a combinação de atributos não for possível formar uma chave
primária coerente, deve-se criar um código sequencial para identificar unicamente cada
entrada da tabela. Por exemplo, na Tabela 7 (Tabela Projetos), a chave da tabela é o código
do projeto que é um sequencial numérico.
12
Banco de Dados
001 SOFTHOUSE
002 GEOPROC
Uma tabela pode incluir entre seus atributos a chave primária de outra tabela.
Essa chave é chamada chave estrangeira. Ou seja, uma chave estrangeira é uma coluna
(ou combinação de colunas) que indica um valor que deve existir como chave primária em
uma outra tabela (chamada de Tabela Pai). Por exemplo, na tabela Alocação (vide Tabela
5), as colunas CPF e Cod_Projeto são chaves estrangeiras, porque elas são chave primária,
respectivamente, das tabelas Empregado (vide Tabela 6) e Projeto (vide Tabela 7).
Vamos definir novamente com outras palavras: uma chave estrangeira de uma
relação R1 é um atributo (ou conjunto de atributos) que referencia a chave primária de uma
outra relação R2. Dessa forma, para qualquer tupla de R1, o valor da chave estrangeira deve
ser igual ao valor da chave primária de alguma tupla da relação R2 referenciada, ou deve ser
o valor nulo (se a chave estrangeira não fizer parte da chave primária da relação R1). Com
isso queremos dizer que o atributo que é chave estrangeira em uma relação R1, pode ou não
fazer parte da chave primária de R1. No exemplo de chave estrangeira dado anteriormente,
as chaves estrangeiras CPF e Cod_Projeto fazem parte da chave primária da tabela Alocação
(vide Tabela 5). Porém, a chave estrangeira pode não fazer parte da chave primária. Observe
a tabela Funcionário (vide Tabela 8). Ela possui um atributo chamado Cod_Depto que
é chave primária da tabela Departamento (vide Tabela 9). Logo, na tabela Funcionário, o
atributo Cod_Depto é uma chave estrangeira. Chaves estrangeiras são indicadas pela sigla
FK (Foreign Key) – vide Tabela 8.
13
Banco de Dados
11 Vendas
22 Financeiro
Uma chave estrangeira formada por mais de uma coluna é chamada de chave
estrangeira composta.
No modelo relacional os relacionamentos representados no MER passam a ser
representados através de chaves estrangeiras. Ou seja, as chaves estrangeiras tornam
possível a associação lógica entre tabelas distintas. Isso ficará mais claro no próximo capítulo
quando forem apresentadas as regras de derivação do MR a partir do MER.
Refere-se às chaves primárias e procura garantir que toda e qualquer linha de uma
tabela deve poder ser acessada com base apenas no conteúdo de sua chave primária. Para
isso, algumas regras devem ser observadas:
Integridade Referencial
15
Banco de Dados
Observação
Uma chave estrangeira pode referenciar-se a um atributo da sua própria tabela (caso que
ocorrerá com os auto-relacionamentos do MER). Por exemplo, a tabela Funcionário (vide
Tabela 11) poderia ter, para cada funcionário, quem é o seu supervisor direto. Assim, o campo
CPF_Supervisor, que é considerado chave estrangeira, é a chave primária da própria tabela
Funcionário e não de outra tabela qualquer.
16
Banco de Dados
As restrições de integridade devem ser implementadas pelo SGBD. Muitos SGBD’s implementam
integridade de entidade, mas não implementam integridade referencial.
17
Banco de Dados
Conheça Mais
Neste capítulo foram vistos conceitos básicos do modelo relacional. Para obter mais
informações ou materiais diversificados para o que foi visto aqui, você pode proceder a
uma pesquisa usando o Google (www.google.com.br) com as palavras chaves “Modelagem
Lógica” + “Banco de Dados” ou “Modelo Relacional” ou ainda “Esquema Relacional”. Você
vai ver que virá muito material. Entre eles: apostilas, notas de aula, reportagens, etc.
Adicionalmente, você pode consultar qualquer livro sobre banco de dados,
pois qualquer um deles terá um ou mais capítulos voltados para a explicação do modelo
relacional. Entre os livros que podemos indicar estão:
18
Banco de Dados
Você Sabia?
As 12 Regras de Codd
Você sabia que Edgard F. Codd, em 1985, estabeleceu as 12 regras de Codd que
determinam o quanto um banco de dados é relacional? Pois é. A título de conhecimento,
vamos apresentá-las a seguir. Lembramos que nem todas as regras serão completamente
compreendidas nesse momento, mas o serão até o final da disciplina. Adicionalmente, vale
a pena saber que nem todos os SGBDs relacionais fornecem suporte a todas elas.
Regra 1 - Regra das informações em tabelas: As informações a serem armazenadas
no banco de dados devem ser apresentadas como relações (tabelas formadas por linhas e
colunas) e o vínculo de dados entre as tabelas deve ser estabelecido por meio de valores de
campos comuns (chaves estrangeiras).
Regra 2 - Regra de acesso garantido: Todo e qualquer valor atômico em um BD
relacional possui a garantia de ser logicamente acessado pela combinação do nome da
tabela, do valor da chave primária e do nome do campo/coluna que deseja acessar. Isso
porque, com o nome da tabela, se localiza a tabela desejada. Com o valor da chave primária
a tupla desejada dentro da tabela é localizada. E com o nome do campo/coluna se acessa a
parte desejada da tupla.
Regra 3 - Regra de tratamento sistemático de valores nulos: Valores nulos devem
ser suportados de forma sistemática e independente do tipo de dado para representar
informações inexistentes e informações inaplicáveis. Deve-se sempre lembrar que valores
nulos devem ter um tratamento diferente de “valores em branco”.
Comentário
Regra 4 - Regra do catálogo relacional ativo: Toda a estrutura do banco de dados
(domínios, campos, tabelas, regras de integridade, índices, etc) deve estar disponível em 7
Veremos como fazer
tabelas (também referenciadas como catálogo). Sua manipulação é possível por meio de isso no último volume
linguagens específicas (por exemplo, SQL). Essas tabelas são, geralmente, manipuladas pelo desta disicplina,
quando estivermos
próprio sistema no momento em que o usuário efetua alterações na estrutura do banco de estudando a linguagem
dados (por exemplo, a inclusão de um novo atributo em uma tabela). SQL.
Regra 5 - Regras de atualização de alto-nível: Essa regra diz que o usuário deve
ter capacidade de manipular as informações do banco de dados em grupos de registros, ou
seja, ser capaz de inserir, alterar e excluir vários registros ao mesmo tempo7.
Regra 6 - Regra de sub-linguagem de dados abrangente: Pelo menos uma
linguagem, com sintaxe bem definida, deve ser suportada, para que o usuário possa
19
Banco de Dados
Aprenda Praticando
20
Banco de Dados
21
Banco de Dados
(Administrador/PM SANTOS/FCC/2005)
Respostas:
1) E – O domínio de um atributo são os valores que ele pode assumir. Ou seja, é o tipo
deste atributo. Por exemplo, o atributo dia do mês tem como domínio os valores
naturais entre 1 e 31.
2) C – A cardinalidade de uma relação é o número de linhas ou tuplas dessa relação.
Assim, uma relação com quatro tuplas, tem cardinalidade 4.
3) B – Uma chave estrangeira pode não pertencer à chave primária, não pode conter
valores que não existam na tabela-pai e só podem assumir valor nulo se não
pertencer à chave primária da tabela onde é chave estrangeira.
4) E – Integridade Referencial. Ela checa todas as validações necessárias referentes ao
uso de chaves estrangeiras.
5) C – Os dois principais tipos de integridade que podem ser verificados em um BD
relacional são a integridade de entidade (que se referem às checagens da chave
primária) e a integriadade referencial (que se refere às checagens da chave
estrangeira).
6) D – Nome do funcionário é tipicamente um atributo e um atributo é representado
no BD relacional por uma coluna.
Agora vamos exercitar o que foi estudado neste capítulo. Assim sendo, faça as
atividades sugeridas a seguir. Lembre que exercitar vai ajudá-lo(a) a fixar melhor o conteúdo
estudado. E o conteúdo desse capítulo é fundamental para o capítulo seguinte, onde vamos
aprender a construir o Modelo Relacional. Mãos à obra!
Atividades Práticas:
Disciplina(CodigoDisciplina,Nome,Creditos,CodigoDepartamento)
Curriculo(CodigoCurso,CodigoDisciplina,Obrigatória-Opcional)
Conceito(CodigoAluno,CodigoDisciplina,Ano-Semestre,Conceito)
Departamento(CodigoDepartamento,Nome)
10
Aproveitamos
A partir desse esquema, explique que verificações/checagens deveriam ser feitas esse exercício para
pelo SGBD para garantir integridade referencial nas seguintes situações: lembrar que quando
um campo é chave
a) Uma linha é incluída na tabela Consulta. estrangeira e também
chave primária
b) Uma linha é excluída da tabela Paciente. de uma tabela,
a representação
predominante é a
de chave primária.
Por isso, apesar de
Vamos Revisar? CodigoConvenio,
NumeroPaciente e
CRM serem chaves
estrangeiras vindas
Você estudou, neste capítulo, os conceitos básicos referentes ao modelo relacional. das tabelas Convenio,
Entre eles, os conceitos de tabela ou relação, tuplas ou linhas, atributos ou colunas e chaves Paciente e Médico,
respectivamente, o
(chave candidata, primária, secundária e estrangeira). Esses conceitos serão todos utilizados símbolo usado ao lado
no próximo capítulo onde você aprenderá a derivar o modelo relacional a partir do modelo dos atributos é o PK de
entidade-relacionamento. Adicionalmente, foram vistos também neste capítulo os principais chave primária.
tipos de integridade (de entidade e referencial), além de integridades complementares e
integridade semântica.
23
Banco de Dados
Capítulo 8
Metas
24
Banco de Dados
Neste capítulo, você vai aprender como derivar o MR a partir do MER, para isso,
todas as instruções de como fazer isso serão dadas. Vamos lá?
25
Banco de Dados
26
Banco de Dados
28
Banco de Dados
29
Banco de Dados
30
Banco de Dados
32
Banco de Dados
Se a especialização não for mutuamente exclusiva, deve ser criada uma tabela
para cada entidade, todas tendo como chave primária o atributo identificador da entidade
principal (de nível superior). Por exemplo, vide a Figura 14. Uma conta pode ser apenas
uma conta normal, pode ser uma poupança ou uma conta de investimento. Assim, a
especialização não é mutuamente exclusiva, como consequência, cada entidade dará
origem a uma tabela e todas terão como chave primária a chave da entidade principal.
33
Banco de Dados
34
Banco de Dados
35
Banco de Dados
Considerações Finais
O principal ponto que deve ser considerado em um esquema relacional, quando
comparado ao esquema do MER, é que os relacionamento não são mais representados
explicitamente. Eles passam a ser representados no MR através do uso de chaves
estrangeiras.
Uma vez que o modelo relacional esteja pronto, ele deve ser normalizado
(otimizado). "Como fazer isso" é assunto do próximo capítulo. Depois, com o MR
Normalizado, o projeto do banco de dados estará pronto para passar da sua fase lógica
(Projeto Lógico), para a fase física, o Projeto Físico ou de Implementação.
Conheça Mais
Alguns livros que podem ser usados para aprofundar o estudo nesse capítulo são:
36
Banco de Dados
Aprenda Praticando
Não é tão complicado! Quanto mais você exercitar, mais vai memorizar as regras e
conseguir aplicá-las com mais facilidade. Porém, para isso, você realmente precisa praticar!
Atividades Práticas
a) Controle Acadêmico
38
Banco de Dados
b) Controle Farmácia
Vamos Revisar?
39
Banco de Dados
Capítulo 9
» Dependências Funcionais.
» Normalização de Dados.
Metas
40
Banco de Dados
Projetar um banco de dados relacional significa agrupar atributos para formar bons
esquemas de relações. Mas o que seria um bom esquema? Em nível geral, poderíamos dizer
que seria um esquema fácil de entender e em que as tuplas da relação fossem armazenadas
e acessadas de forma eficiente. Para isso, é preciso que sejam minimizadas, ao máximo,
a redundância nos dados e as anomalias de inserção, atualização e exclusão. Além disso,
é preciso garantir a integridade dos dados, evitando que informações sem sentido sejam
inseridas e é preciso organizar e dividir as tabelas da forma mais eficiente possível. Uma
forma de colaborar com essas necessidades é fazer a normalização dos dados. Esse é
justamente o assunto deste capítulo.
Neste capítulo, estudaremos o que são dependências funcionais, seu impacto sobre
os dados e como realizar a otimização do MR através da normalização dos dados. Vamos lá?
Dependências Funcionais
Sempre que um atributo X identifica um atributo Y dizemos que entre eles há uma
Você Sabia?
dependência funcional12. Temos, portanto, que X é o determinante e que Y é o dependente.
A representação é: X → Y. Em outras palavras, se o valor de um atributo X permite descobrir
12
O Modelo Relacional
o valor de um outro atributo Y, dizemos que X determina funcionalmente Y. Por exemplo, pegou emprestado da
dada uma determinada cidade (não considerando cidades homônimas) sabemos o seu teoria de funções da
estado e com o estado temos o país. Isso é representado da seguinte forma: matemática o conceito
de dependência
Cidade → estado funcional.
Estado → país
Em outras palavras, estado é funcionalmente dependente de cidade e país é
funcionalmente dependente de estado. Ou ainda, cidade determina estado e estado
determina país.
Logo, a dependência funcional é caracterizada pela existência de campos em uma
determinada tabela relacional cuja ocorrência de valores está associada a valores que
são preenchidos em outros campos na mesma tabela. Por exemplo, suponha uma tabela
EMPREGADO que possui dois atributos CPF e NOME. O atributo NOME é funcionalmente
dependente do atributo CPF. Assim, CPF → Nome. Com isso, queremos dizer que nome é
função do CPF, ou seja, se eu tiver um número de CPF, poderei encontrar o nome da pessoa
correspondente. Em outras palavras, CPF determina o Nome (vide Figura 17).
41
Banco de Dados
CPF_Empregado Cod_
Nome_Empregado Nome_Projeto Horas_Trabalhadas
(PK) Projeto (PK)
42
Banco de Dados
Por exemplo, a relação Pedido_Venda (vide Tabela 13) tem como chave primária
o atributo Cod_Pedido. Os atributos Data_Pedido, Situação_Pedido e CPF_Cliente
dependem funcionalmente dessa chave primária. Porém, o atributo Nome_Cliente depende
funcionalmente do CPF_Cliente (que não é a chave primária) e, apenas, indiretamente do
Cod_Pedido, o que é uma anomalia, visto que, todos os atributos de uma relação deveriam
depender funcionalmente apenas da sua chave primária.
Cod_Pedido
Data_Pedido Situação_Pedido CPF_Cliente Nome_Cliente
(PK)
Uma dependência funcional (DF) é uma propriedade do esquema da relação e não de uma
instância particular da relação (tupla). Assim, uma DF não pode ser automaticamente inferida a
partir de algumas tuplas da relação, mas deve ser definida por alguém que conheça a semântica
dos atributos da relação. Isso, porque a DF deve ser válida para todas as tuplas de uma relação, ou
seja, para a definição do esquema da relação como um todo.
Anomalias de Atualização
A mistura de atributos de várias entidades pode gerar problemas conhecidos como
anomalias de atualização e essas anomalias podem, por sua vez, causar problemas tais
como a ocorrência de:
43
Banco de Dados
Nome_Cliente
Cod_CD (PK) Dt_Compra (PK) Nome_CD Cantor Preço
(PK)
Agora imagine a seguinte situação: o cliente João Pontes deseja comprar 5 CDs
iguais (por exemplo, Perfil de Ivete Sangalo, que custa 15 reais). Como essa operação
refletiria na Relação Vendas? Seria possível realizá-la?
O primeiro problema seria: como não podemos ter mais de uma tupla com a
mesma chave primária, o cliente não poderia comprar os 5 cds no mesmo dia. Isso, porque,
se comprasse, haveria 5 tuplas com a mesma chave primária (Nome_Cliente, Cod_CD e Dt_
Compra), o que não seria possível. Se o cliente comprasse em dias diferentes, mesmo assim,
poderiam ser observadas as seguintes anomalias:
44
Banco de Dados
O que é Normalização?
Em 1970, o Professor Dr. Edgar F. Codd13, analista da IBM, desenvolveu uma série Comentário
de estudos sobre como tratar os dados, a fim de eliminar as anomalias de atualização e
as suas consequências desagradáveis para as organizações. Deste esforço surgiram duas 13
Já falamos sobre ele,
inovações que revolucionaram a maneira de tratar os dados. A primeira destas inovações lembra?
foi o Modelo Relacional, no qual se basearam os Sistemas Gerenciadores de Base de Dados
45
Banco de Dados
(SGBD) da metade da década de 1980 e início de 1990. A segunda inovação foi o processo
de Normalização, sendo que ambas estão intimamente relacionadas.
O processo de normalização como foi proposto por Codd sujeita um esquema de
relação a uma série de testes para certificar-se de que ele satisfaça certa forma normal.
Na verdade, a normalização de dados pode ser vista como o processo de análise de
determinados esquemas de relações com base em suas dependências funcionais e chaves
primárias para alcançar as propriedades desejáveis de: (1) minimização de redundâncias e (2)
minimização de anomalias de inserção, exclusão e alteração. Nesse processo, os esquemas
de relações insatisfatórios, que não alcançam certas condições (no caso, os testes de forma
normal) são decompostos em esquemas de relações menores que passam nos testes e,
consequentemente, possuem as propriedades desejadas. Em outras palavras, quando uma
tabela não atende ao critério de uma forma normal, sua estrutura é redesenhada através
da projeção (jogar para fora) de alguns atributos, levando a construção de novas tabelas
contendo algum atributo que possa refazer o conteúdo da tabela original através da junção
(reunir) das tabelas resultantes.
Assim, podemos dizer que o processo de normalização tem as seguintes funções:
» Analisar tabelas e organizá-las de forma que a sua estrutura seja simples, relacional
e estável, para que o gerenciamento delas possa ser também simples, eficiente e
seguro;
» Evitar a perda e a repetição da informação;
» Conseguir uma forma de representação adequada para o que se deseja armazenar;
» Oferecer mecanismos para analisar o projeto do BD (identificação de erros e
possibilidades de melhorias) e oferecer métodos para corrigir problemas que, por
ventura, sejam encontrados.
E, com essas funções, pretende-se alcançar os seguintes objetivos:
» Garantir a integridade dos dados, evitando que informações sem sentido sejam
inseridas no banco de dados;
» Organizar e dividir as tabelas da forma mais eficiente possível, diminuindo a
redundância e permitindo a evolução do banco de dados com o mínimo de efeito
colateral.
Inicialmente, Codd propôs três formas normais que ele chamou de primeira (1FN),
segunda (2FN) e terceira (3FN) forma normal. Uma definição mais forte da 3FN (chamada
forma normal BOYCE-CODD - FNBC ou BCNF) foi depois proposta por Boyce e Codd. Todas
essas formas normais são baseadas nas dependências funcionais entre os atributos de uma
relação. Posteriormente, uma quarta (4FN) e quinta (5FN) forma normal foram propostas
(elas serão apresentadas no Apêndice A).
As formas normais são aplicadas para evitar redundância de dados, inconsistências
e anomalias de atualização. Isso porque, redundância de dados é um fato gerador de
inconsistências. Já as anomalias de atualização criam dificuldades operacionais para
manutenção do banco de dados, quebrando a confiabilidade no dado ou ferindo a
integridade dos dados.
Uma forma normal engloba todas as outras anteriores, ou seja, a hierarquia entre
as formas normais indica que uma tabela só pode estar numa forma mais avançada se, além
de atender as condições necessárias, já estiver na forma normal imediatamente anterior.
Por exemplo, para que uma tabela esteja na 2FN, ela obrigatoriamente deve estar na 1FN e
assim por diante.
Na prática, o mais comum é normalizar relações apenas até a 3FN. Isso porque
46
Banco de Dados
as três primeiras formas normais (1FN, 2FN e 3FN) atendem a maioria dos casos de
normalização e já são suficientes para organizar as tabelas de um BD.
Apresentaremos cada uma das formas normais nas seções a seguir, ilustrando cada
uma delas com exemplos.
I) Atributos Compostos - cada um dos atributos compostos (ou não atômicos) devem
ser “divididos” em seus atributos componentes. Por exemplo, na Tabela 16, o
atributo “Graus_Lentes” poderia ser subdivido em Grau_LenteEsq e Grau_LenteDir,
visto que temos de armazenar o grau de cada olho separadamente, quebrando
assim o atributo composto nos dois outros que o compõe. Com essa quebra,
ficaríamos com a relação apresentada na Tabela 18. Observe que, agora, todos os
atributos são indivisíveis (atômicos).
47
Banco de Dados
Tabela 19 - Relação Matricula (na 1FN, considerando quantidade pequena e conhecida de valores)
48
Banco de Dados
123456 Programador
123456 Arquiteto
987659 Analista
007543 Operador
007543 Programador
007543 Analista
Mesmo que uma relação esteja na 1FN, ela pode apresentar redundâncias e
anomalias de atualização. Para eliminar ou minimizar estes problemas, devemos prosseguir
no processo de normalização, aplicando as outras formas normais.
Dica
Relações na 1FN e que possuam chave primária simples estão, automaticamente, na 2FN.
Por exemplo, veja a Relação Alocação (vide Tabela 22). Ela possui a chave composta
CPF_Empregdo e Cod_Projeto. Essa relação se encontra na 1FN porque não possui atributos
multivalorados ou compostos. Porém, não está na 2FN porque o campo Nome_Empregado
depende apenas de parte da chave primária (no caso, do CPF_Empregado) e o atributo
49
Banco de Dados
CPF_Empregado Cod_Projeto
Nome_Empregado Nome_Projeto Horas_Trabalhadas
(PK) (PK)
E como faríamos para passar uma relação para a 2FN? Para passarmos uma
entidade da 1FN para a 2FN, devemos eliminar as dependências parciais. E como fazer isso?
1) Para cada atributo que não faça parte da chave primária da relação, analisar se
existe dependência parcial da chave primária. Para identificar a dependência parcial
de uma coluna em relação à chave primária, deve-se indagar: Para que o valor
do atributo seja determinado, quais as partes da chave primária que devem ser
conhecidas?
2) Para cada grupo de atributos que tenham a mesma dependência parcial da chave
primária, devem-se criar novas relações (tabelas) que terão como chave primária
a chave parcial que estava na relação original e todo o grupo de atributos que
depende da mesma chave parcial;
3) Excluir da relação original o grupo de atributos para o qual foi criada uma nova
relação;
4) Repetir esses procedimentos para cada grupo de atributos que tenha dependência
parcial da chave primária da relação original, até que todas as relações somente
contenham atributos que dependam de toda a chave primária.
Por exemplo, a relação Alocação (Tabela 22) daria origem a duas novas relações14
Dica (vide Tabelas 23 e 24), uma vez que há dois grupos e dependências parciais nesta relação:
14
O nome das novas Cod_Projeto a NomeProjeto e CPF_Empregado a Nome_Empregado. Veja que em cada nova
relações deve ser relação criada, foi colocada a parte da chave primária da tabela original da qual o atributo
escolhido de acordo depende. E, posteriormente, os atributos que tinham dependência parcial foram retirados
com suas chaves
da relação original (vide Tabela 25), só ficando nela o atributo (no caso Horas_Trabalhadas)
primárias.
que dependia da chave primária completa.
50
Banco de Dados
11 SoftHouse
22 HardCore
33 LinuxP
123456 11 40
654321 22 20
789654 33 40
11 IP S15 6
22 IP S16 6
11 BD S02 4
22 SO S10 4
22 SO S12 4
E, então, como ficaria essa relação Turma (Tabela 26) na 2FN? Observe as Tabelas
27 e 28 e reflita sobre como elas foram obtidas.
51
Banco de Dados
IP 6
BD 4
SO 4
11 IP S15
22 IP S16
11 BD S02
11 SO S10
22 SO S12
Dica
Relações que estejam na 2FN e que não tenham nenhum ou apenas um atributo além da chave
estão automaticamente na 3FN.
Por exemplo, observe a relação Funcionário (Tabela 29). Ela está na 2FN porque
não contém chave composta. Porém, há uma dependência transitiva na mesma. O atributo
Salário depende do atributo Cargo (que não faz parte da chave primária). Já o atributo Cargo,
por sua vez, depende da chave primária Cod_Empregado. Assim, temos: Cod_Empregado
→ Cargo → Salário.
52
Banco de Dados
E como faríamos para passar uma relação para a 3FN? Para passarmos uma
entidade da 2FN para a 3FN, devemos eliminar as dependências transitivas. E como fazer
isso?
1) Para cada atributo que não participe da chave primária da relação, analisar se existe
dependência transitiva da chave primária. Para identificar a dependência transitiva
de um atributo deve-se indagar: Qual outro atributo não pertencente à chave e
poderia determinar o valor do atributo em análise? Ou seja, você vai analisar se
o valor de um atributo não-chave pode ser determinado por algum outro atributo
que também não pertença à chave primária da relação;
2) Para cada grupo de atributos não-chaves dependentes funcionalmente de outros
atributos não-chaves, cria-se uma nova relação. Essa nova relação vai ter os
atributos dependentes como não-chaves e os atributos que causam a dependência
(determinantes) como chave primária. Ou seja, vai ser chave primária da nova
relação os atributos dos quais os atributos não-chave da relação original dependem.
O nome das novas relações deve ser escolhido de acordo com a chave primária das
mesmas;
3) Repetir os passos anteriores até que todos os atributos restantes na relação original
dependam diretamente de toda a chave primária. Em outras palavras, repete-se
até que todas as relações não contenham atributos dependentes de atributos não-
chaves;
4) Excluir da tabela original todos os atributos com dependência transitiva, mantendo
o atributo determinante da transitividade. Deve-se excluir, também, os atributos
derivados a partir de outros (atributos calculados), por exemplo, se houver um
atributo data de nascimento e outro atributo idade, o atributo idade deve ser
excluído, uma vez que, a qualquer momento, ele poderá ser calculado a partir do
atributo data de nascimento.
Vamos exemplificar. Para passar a Tabela 29 para a 3FN, iríamos criar uma nova
relação (que chamamos de Salario_Cargo, vide Tabela 30) que terá como chave primária o
atributo não-chave determinante da dependência transitiva (no caso, o Cargo) e o atributo
não-chave dependente (no caso Salário), uma vez que Cargo a Salário na relação Funcionário
original (vide Tabela 29). Depois, o atributo em dependência transitiva deve ser retirado
da relação original (no caso, Salário é retirado da relação Funcionário – vide Tabela 31).
Assim, a relação original fica apenas com atributos que dependem funcionalmente apenas
da chave primária (no caso, Cod_Empregado).
Programador 2000
Analista 3500
53
Banco de Dados
E, então, como ficaria essa relação Turma (Tabela 32) na 3FN? Observe as Tabelas
33 e 34 e reflita sobre como elas foram obtidas.
S09 40
S23 50
54
Banco de Dados
Observação
Na prática, quando um esquema relacional está na 3NF, normalmente, também está na BCNF.
A exceção é quando existe uma dependência X → A onde X não é uma superchave e A é um
atributo da chave (vide Figura 19).
55
Banco de Dados
Joana Mendes IP
Paulo Bennet BD
56
Banco de Dados
» Avalie se vale a pena aplicar mais algum tipo adicional de normalização 4FN, 5FN e
FNBC.
» O que fazer se você não conseguir definir uma chave primária? Realmente, poderá
haver algumas ocasiões que, no momento da geração da estrutura de tabelas, você
não consiga determinar um ou mais atributos que garantam a identificação única de
alguma relação, ou seja, não conseguirá definir uma chave primária. Nestes casos,
será necessário criar um atributo artificial (por exemplo, um código, geralmente,
sequencial) para servir como chave primária.
» Atributos Irrelevantes devem ser desconsiderados – Alguns atributos de um
relatório não necessitam estar armazenados em um BD, pois serão determinados
em tempo de execução. Por exemplo, número de páginas de um relatório ou a sua
data de emissão. Estes dados não devem ser considerados atributos da estrutura de
tabelas aninhadas.
» Atributos derivados também podem ser desconsiderados – Informações que são
deduzidas a partir de dados do BD, como cálculos (somas, médias, valor máximo)
ou a idade, que pode ser deduzida a partir da data do nascimento podem ser
eliminadas do conjunto de atributos da estrutura de tabelas aninhadas. Esta
afirmação não é uma exigência. Isso porque, às vezes, um somatório, por exemplo,
é solicitado com tanta frequência em uma consulta, que se torna mais eficaz manter
o seu resultado no BD, do que calculá-lo diversas vezes em pouco tempo.
» Valores Nulos em Tuplas – as relações devem ser projetadas de forma que suas
tuplas tenham a menor quantidade possível de valores nulos. Normalmente, os
atributos que possuem valores nulos podem ser colocados em relações separadas.
E quais as razões para se usarem valores nulos? Quando o valor é não aplicável
ou inválido, quando o valor é desconhecido (embora possa existir) ou está,
temporariamente, indisponível (embora se saiba que ele exista).
» Tuplas Espúrias - projetos incorretos de bancos de dados relacionais podem gerar
resultados inválidos (tuplas espúrias) em certas operações de junção de relações16
Comentário
(Join). A propriedade de “junção sem perdas” é usada para garantir resultados
corretos em operações de junção, de forma que nenhuma tupla espúria seja gerada.
16
Quando relações
são combinadas a
partir de um atributo
Considerações Finais (geralmente a chave
primária) em comum.
57
Banco de Dados
Saiba Mais
Aprenda Praticando
58
Banco de Dados
TABELA_PEDIDO
Num_ Cod_
Nm_ Endereço_ Preço_
Pedido Prod Nm_Prod Data Qtd
Fornecedor Fornec Total
(PK) (PK)
Em uma primeira avaliação, já podemos verificar que a tabela Pedido não está na
1FN, pois há vários atributos não atômicos, ou seja, atributos multi-valorados. Para deixar a
tabela em 1FN é preciso dividir esses atributos em linhas. Com isso, ficamos com a tabela a
seguir.
TABELA_PEDIDO
Num_ Cod_
Nm_ Endereço_ Preço_
Pedido Prod Nm_Prod Data Qtd
Fornecedor Fornec Total
(PK) (PK)
Reavaliando a tabela, podemos perceber que ela não se encontra na 2FN, pois
há atributos que dependem apenas de parte da chave primária composta (dependência
parcial). Quais seriam? Temos que: Data, Nm_Fornecedor e Endereco dependem apenas de
Num_Pedido. Nm_Prod depende apenas de Cod_Produto. Apenas Qtd e Preco dependem
da chave composta. Assim redividimos as tabelas, segundo essas dependências e ficamos
com:
TABELA_PEDIDO
59
Banco de Dados
TABELA_PRODUTO
001 Photoshop
002 Coreldraw
003 Flash
005 ABC
TABELA_PRODUTOS_PEDIDO
TABELA_PEDIDO
TABELA_FORNECEDOR
InfoSoft R. Flor, 25
60
Banco de Dados
Você Sabia?
Você sabia que, algumas vezes, precisaremos fazer uma desnormalização do Banco de Dados?
Mas o que é isso? Desnormalização é uma técnica usada para converter uma ou mais tabelas
relacionadas em uma única tabela com informações possivelmente redundantes, a fim de
melhorar o desempenho no acesso aos dados. Essa técnica é usada em casos particulares para
evitar junções e proporcionar agilidade nas consultas aos dados, como no caso do projeto de
data warehouses.
Agora é a sua vez de fazer as atividades! Lembre que praticar é muito importante
para fixar o conteúdo estudado!
Atividades Práticas:
I) Faça a Normalização, pelo menos até a 3FN, das relações a seguir. Atributos entre
chaves indicam atributos multivalorados. Atributos sublinhados indicam as chaves
primárias.
a) Tabela_Oficina (cod_cliente, nome, endereco, cod_carro, modelo, ano_
fabricacao, {cod_servico, descricao}, data_servico,valor_servico,{cod_produto,
nome_produto})
b) Tabela_Hospital (cod_paciente, nome, tel, endereco, crm, nome_med, tel_med,
endereco_med, cod_especialidade, nome_espec, data_consulta, diagnostico)
c) Tabela_Locadora (cod_cliente, nome, tel, {cod_fita, nome_filme, duracao, cod_
genero, descricao}, data_locacao, data_devolucao, valor)
d) Tabela_Estoque (cod_peca, descricao, quantidade_comprada, {cod_fornecedor,
nome, telefone})
e) Tabela_Biblioteca (cod_aluno, nome, telefone, end, {cod_livro, titulo, editora,
volume, cod_autor, nome, genero}, data_emprestimo, data_devolucao)
f) Tabela_Matricula (cod_aluno, cod_turma, cod_disciplina, nome_disciplina,
nome_aluno, cod_localnascaluno, nome_localnascaluno)
g) Tabela_Consulta (cod_medico, nome_med, crm, fone, cod_paciente, nome_
pac, fone_pac, end_pac, dt_consulta, diagnostico)
II) Considere a relação para livros publicados:
LIVRO (título_livro, nome_autor, tipo_livro, preço_tabela, afiliação_autor, editora)
Suponha as que existam as seguintes dependências:
título_livro → editora, tipo_livro
tipo_livro → preço_tabela
nome_autor → afiliação_autor
61
Banco de Dados
Vamos Revisar?
62
Banco de Dados
Apêndice A
Metas
» Conhecer outros tipos de normalização que podem vir a serem necessários para
otimizar as tabelas do Banco de Dados.
63
Banco de Dados
Observação
Por exemplo, analise a relação Alocação_Professor (vide Tabela 35). Nela temos
as seguintes multi-dependências funcionais: Nome_Prof → → Sigla_Disciplina (ou seja, a
partir do nome do professor podemos saber as disciplina que ele ministra) e Nome_Prof
→ → Orientando (ou seja, a partir do nome do professor é possível saber os alunos que ele
orienta).
64
Banco de Dados
Observe que as disciplinas que o professor leciona devem ser independentes dos
alunos que ele orienta. Se a relação acima significasse que o professor orienta determinado
aluno em uma determinada disciplina, a relação estaria correta e não necessitaria ser
normalizada. Porém, estamos considerando multi-dependências funcionais entre atributos
independentes.
Relações que não estão na 4FN podem apresentar problemas de inconsistências
devido à duplicidade dos dados. Por exemplo, na Tabela 35, o professor “André Fernandes”
só tem um orientando “Tadeu Batista”, mas ministra duas disciplinas. Devido a esse fato,
o nome do orientando precisou ser duplicado sem necessidade. O mesmo ocorreu com o
professor “Jorge Macedo” que só ministra uma disciplina “IP” e possui dois orientandos
(houve duplicação da sigla da disciplina). Adicionalmente, relações desse tipo podem
apresentar anomalias de atualização, por exemplo:
André Fernandes BD
André Fernandes ES
Jorge Macedo IP
Márcia Gadelha SO
Veja que, agora, assuntos diferentes são tratados em relações diferentes, evitando
duplicações e anomalias.
65
Banco de Dados
Dependência de Junção: Dada uma relação R e certas projeções (subconjuntos da relação) R1,..., Rn
diz-se que há uma dependência de junção (de R em relação a R1,..., Rn) se R pode ser reconstituída
com a junção de R1,..., Rn.
Em outras palavras, uma relação na 4FN estará na 5FN, quando seu conteúdo não
puder ser reconstruído (junção), porque há perda de informação, a partir das diversas
relações menores (subconjuntos extraídos da relação principal). Ou seja, se ao particionar
uma relação, sua junção posterior não conseguir recuperar as informações contidas na
relação original, então esta relação está na 5FN.
Assim, se uma relação não está na 5ªFN, então, existe uma decomposição de
R em um conjunto de projeções (subconjuntos) que estão na 5ªFN e cuja junção natural
restabelece a relação original. Esta forma normal trata especificamente dos casos de perda
de informação, quando da decomposição de relacionamentos múltiplos.
Para exemplificar, pode acontecer de uma tabela representar um relacionamento
triplo que não pode ser simplificado, pois se for quebrado em relacionamentos binários
poderá gerar informações incorretas. Neste caso, a tabela já está na 5FN. Para checar esse
fato, pode-se utilizar a seguinte pergunta: é possível substituir o relacionamento ternário
por relacionamentos binários?
Vamos a outro exemplo. Se um vendedor vende certo tipo de veículo e ele
representa o fabricante daquele tipo de veículo, então ele vende aquele tipo de veículo
para aquele fabricante (regra de simetria), tal como representado na relação Vendas (vide
Tabela 41). Essa relação pode ser decomposta em três outras relações, portanto não está
na 5NF (observe que há uma redundância de informações na relação, que irá requerer mais
atenção na atualização de dados).
66
Banco de Dados
André Fernandes GM
Ford Automóvel
Ford Caminhão
GM Automóvel
GM Caminhão
67
Banco de Dados
Considerações Finais
Olá, cursista!
Esperamos que você tenha aproveitado este terceiro módulo da disciplina Banco de
Dados. Com os assuntos vistos até agora, você já tem tudo para criar o seu banco de dados
e começar a trabalhar com ele, armazenando, alterando, deletando e consultado os dados
armazenados. É justamente isto que estudaremos no próximo módulo: a linguagem SQL que
vai lhe ajudar a criar e manipular o seu banco de dados!
Aguardamos sua participação no próximo módulo.
Até lá e bons estudos!
Sandra de Albuquerque Siebra
Autora
68
Banco de Dados
Referências
69
Banco de Dados
Conheça a Autora
70