Académique Documents
Professionnel Documents
Culture Documents
Julho de 2009
alvaro_pimentel@uol.com.br
Resumo Este manual uma continuao da proposta de discusso de acesso aberto, iniciada no artigo Open Access: Ser ou no ser?, que est disponvel no endereo http://artigocientifico.tebas.kinghost.net/pesquisadores/?mnu=2&smnu=5&id=29536, e corresponde segunda parte do material que foi disponibilizado primeiramente no manual Free Acess: O MySQL na prtica, tambm no mesmo endereo acima, o qual apresenta a implementao de uma base de dados MySQL. Neste manual sero apresentados os mtodos bsicos para a modelagem de dados que incluem tpicos de abstrao, modelagem lgica, fsica e normalizao. Alm disso, composto de uma srie de exerccios resolvidos que podem ser utilizados para treinar, e serem discutidos, a cada parte avanada. A ltima parte da proposta de disseminao de conhecimentos ser a apresentao de uma apostila de uso das ferramentas CASE MySQL Workbench e MySQL Query Browser. Palavras Chave: Modelagem de dados, Normalizao, Abstrao
14
Abstract This manual is a continuation of proposal open access discussion that began in the article Open Access: To be or not?, and it corresponds to the second part of the material that is available first in the manual Free Access: The MySQL in the practice which presents the construction of a MySQL database. In this manual will be presented the basic methods for the data modeling that include abstraction topics, logical\physical modeling and normalization. Moreover, is composed of a series of exercises that can be used to train, and to be argued, to each advanced part. The last part of the proposal of dissemination of knowledge will be the presentation of use of the tools CASE MySQL Workbench and MySQL Query Browser. Key Words: Data modeling, Normalization, Abstraction
Julho de 2009
alvaro_pimentel@uol.com.br
1. 2.
Tpicos Introduo Conceitos Bsicos 2.1 2.2 2.3 2.4 Bases de Dados Sistemas de Gerenciamento de Bases de Dados Sistemas de Bases de Dados Objetivos de um Sistema de Bases de Dados
3. 4.
14
o de um Modelo de Dados
4.1.2
de Dados Baseado em Registros 4.1.3.1 Modelo de Dados Relacional 4.1.3.2 Modelo de Dados em Rede 4.1.3.3 Modelo de Dados Hierrquico
5.
Definio e Manipulao de Dados 5.1 5.2 5.3 DDL DML DLL Usurios Administrador
6.2.1
6.
Julho de 2009
strao de Bases de Dados (ABD) Modelo Entidade Relacionamento (MER) 7.1 Definio
7.
7.2 Objetivo 7.3 Fases do Projeto de Bases de Dados 7.3.1 CDM Conceptual Data Model 7.3.2 LDM Logical Data Model 7.3.3 PDM Physical Data Model Entidades e Conjuntos-Entidade 8.1 Componentes do Diagrama E-R (Peter Chen):
9.
13 13 13 13 13 13 13 14 15 15 15 16 16 19 19 20 21 21 21 22 22 23 25 27 28 28 30
14
8.
Relacionamentos Restries de Mapeamento (Cardinalidade) 11.1 Um-para-um 11.2 Um-para-muitos 11.3 Muitos-para-muitos
12.
Exerccios 17
13. 14. 15. 16.
Projeto de Chaves Auto-Relacionamento Agregao Generalizao Especializao 16.1 Total e Parcial 16.2 No-Exclusiva 16.3 Mltipla
Relacionamentos de Grau Superior a 2 Dependncia Existencial e Entidades Fracas Exerccios Normalizao 20.1 Primeira Forma Normal (1FN) 20.2 Segunda Forma Normal (2FN) 20.3 Terceira Forma Normal (3FN)
alvaro_pimentel@uol.com.br
Julho de 2009
20.
21 22
Exerccios Solues 22.1 Solues dos exerccios 12.1 a 12.7 22.2 Solues dos exerccios 19.1 a 19.8 22.3 Solues dos exerccios 21.1 a 21.4
31
33 35 39
14
Julho de 2009
alvaro_pimentel@uol.com.br
Introduo
A importncia da informao para a tomada de decises nas organizaes tem impulsionado o desenvolvimento dos sistemas de processamento de informaes. A definio de informao pode ser dada, restringindo-se o seu conceito informtica, como um dado que possui unicidade, atomicidade e que j tenha sido tratado, de tal maneira que agregue significante e significado representando o objeto de origem, real ou abstrato. Vale lembrar que a Cincia da Informao possui uma definio mais abrangente de informao, mas para o estudo de bases de dados, neste nvel, essa mais restrita absolutamente satisfatria. Algumas ferramentas pertinentes ao tratamento da informao:
processadores de texto (editorao eletrnica), planilhas (clculos com tabelas de valores), Sistemas de Gerenciamento de Bancos de Dados - SGBD
1. Conceitos Bsicos
2.1 Bases de Dados
Uma base de dados pode ser definida como uma coleo de dados inter-relacionados representando informaes sobre um domnio especfico.
Exemplos: lista telefnica, controle do acervo de uma biblioteca, sistema de controle dos recursos humanos de uma empresa.
14
Julho de 2009
O sistema de bancos de dados pode ser considerado como uma sala de arquivos eletrnica. Existe uma srie de mtodos, tcnicas e ferramentas que visam sistematizar o desenvolvimento de sistemas de bancos de dados.
alvaro_pimentel@uol.com.br
Vantagens:
rapidez na manipulao e no acesso informao, reduo do esforo humano (desenvolvimento e utilizao), disponibilizao da informao no tempo necessrio, controle integrado de informaes distribudas fisicamente, reduo de redundncia e de inconsistncia de informaes, compartilhamento de dados, aplicao automtica de restries de segurana, reduo de problemas de integridade
14
Programas
Bases de Dados
Usurio
Julho de 2009
alvaro_pimentel@uol.com.br
2. Abstrao de Dados
O sistema de bancos de dados deve prover uma viso abstrata de dados para os usurios. A abstrao se d em trs nveis: Nvel de viso dos usurios
Viso 1
Viso2
..........
Viso N
Conceitual
14
Nvel de Armazenamento
Fsico
descreve partes do banco de dados, de acordo com as necessidades de cada usurio, individualmente.
quais dados esto/sero armazenados e seus relacionamentos. Neste nvel, o banco de dados descrito atravs de estruturas relativamente simples, que podem envolver estruturas complexas no nvel fsico. mais baixo de abstrao. Descreve como os dados esto realmente armazenados, englobando estruturas complexas de baixo nvel.
3. Modelo de Dados
a representao grfica e textual de ESTRUTURAS, OPERADORES e das REGRAS, que definem os dados, assim como as restries de consistncia e integridade
Estruturas
So formadas de Regras (asseres que regulam o funcionamento da estrutura) e Operadores que so comandos que permitem a manipulao das estruturas segundo um comportamento estabelecido.
Anlise das regras de negcio o estudo de anlise dos dados, processos, objetos e
suas correlaes. Divide-se em:
14
Regras de derivao so condies colocadas sobre fatos e que podem gerar outros
fatos.
Ex.: Se um PEDIDO for efetuado at o dia X ele ser processado no ms seguinte.
Julho de 2009
alvaro_pimentel@uol.com.br
4.1.2
Define a descrio dos dados nos nveis conceitual/lgico e de vises de usurios. No modelo orientado a objetos o cdigo executvel parte integrante do modelo de dados.
Ex.: Entidade-Relacionamento. rua nome cidade nmero saldo
CLIENTE
POSSUI
CONTA
4.1.3
14
Define a descrio dos dados nos nveis conceitual/lgico e de vises de usurios; O banco de dados estruturado em registros de formatos fixos, de diversos tipos; Cada tipo de registro tem sua coleo de atributos; H linguagens especficas para expressar consultas e atualizaes no banco de dados.
Ex.: Modelo Relacional, Modelo Hierrquico.
4.1.3.1
Ex.:
cd -cliente
nome
rua
cidade
Tabela Cliente-Conta
Julho de 2009
cd -cliente
alvaro_pimentel@uol.com.br
4.1.3.2
Alvaro
Laura Teles
Rio de Janeiro
900
55
Mrio
Laranjeiras
Rio de Janeiro
556
1000
14
5.366
10.533
Julho de 2009
alvaro_pimentel@uol.com.br
14
Julho de 2009
alvaro_pimentel@uol.com.br
6.1 Usurios
Realizam operaes de manipulao de dados. programadores de aplicaes, usurios sofisticados, usurios especializados, usurios ingnuos.
6.2 Administrador
Pessoa (ou grupo) responsvel pelo controle do sistema de banco de dados. Administrador de Dados Administrador do SGBD 6.2.1
14
Julho de 2009
alvaro_pimentel@uol.com.br
7.2 Objetivo
Facilitar o projeto de bases de dados possibilitando a especificao da estrutura lgica geral do banco de dados
14
8 Entidades e Conjuntos-Entidade
A estrutura lgica geral de um banco de dados pode ser expressa graficamente por um Diagrama Entidade- Relacionamento
Julho de 2009
9 Atributos
So elementos de dados que contm as descries que possibilitam definir uma entidade.
Ex.:
14
Obs: Nenhum modelo suficientemente claro se no for acompanhado de uma definio formal dos elementos e isto feito atravs do Dicionrio de Dados. Ao se modelar deve-se sempre ter em mente que conceitos, aparentemente, triviais a quem est modelando podem no ser para outros profissionais. Assim, o dicionrio de dados tem o objetivo definir as qualificaes, compreender e unificar conceitos dos dados.
Multivalorado: assim definido quando uma nica entidade tem diversos valores para
este atributo. Quando est representado no plural facilmente identificado, porm, em email ou telefone, por estarem no singular, pode criar dvidas quanto qualificao.
Ex.: Dependentes
Julho de 2009
Ex.: Sexo {M, F} Estado civil {CASADO, SOLTEIRO, DIVORCIADO, VIVO, DESQUITADO}
alvaro_pimentel@uol.com.br
10 Relacionamentos
Chama-se de relacionamento a estrutura que indica a associao de elementos de duas ou mais entidades.
Entretanto, em alguns casos, necessrio que os atributos estejam inseridos em uma entidade de juno (ou associativa) para que o relacionamento fique mais bem definido. Neste caso, o atributo de relacionamento aquele que permite efetuar a associao dos conjuntos-entidade.
14
Julho de 2009
alvaro_pimentel@uol.com.br
14
Julho de 2009
alvaro_pimentel@uol.com.br
11.2 Um-para-muitos:
um elemento em A est associado a qualquer nmero de elementos em B, enquanto uma ocorrncia em B est associada somente uma ocorrncia em A.
14
Julho de 2009
alvaro_pimentel@uol.com.br
Exerccios
12.1. Modele o relacionamento de um cliente com um banco considerando os atributos (CLIENTE cpf, nome, idade, endereo; BANCO cdigo do banco. Ignore a aplicao das formas normais 12.2. Modele o relacionamento dos atletas com os esportes de competio (ATLETA nome, idade, peso, pas; ESPORTE tipo, material, local). Ignore a aplicao das formas normais 12.3. Transcreva para linguagem lgica a modelagem conceitual a seguir. 17
CdCli NnCli CdBnc NmBnc
17
CONTRATA BANCO EnBnc
CLIENTE
EnCli
12.4. Mostre como o diagrama abaixo pode ser representado por relacionamentos binrios.
12.5. Modifique o diagrama abaixo para especificar o seguinte: a) Um curso no pode estar vazio, isto , deve possuir alguma disciplina em seu currculo. b) Um aluno pode fazer mais de um curso.
Julho de 2009
alvaro_pimentel@uol.com.br
12.6 Construa um diagrama E-R para um hospital com um conjunto de pacientes e um conjunto de mdicos. Registros de diversos testes realizados so associados a cada paciente.
17
17
12.7 Construa um diagrama E-R para uma companhia de seguros de automveis com um conjunto de clientes, onde cada um possui certo nmero de carros. Cada carro tem um nmero de acidentes associados a ele.
Julho de 2009
alvaro_pimentel@uol.com.br
12 Projeto de Chaves
Aspectos Relevantes
A questo fundamental do projeto de chaves reduzir ao mximo os efeitos de redundncia. A alterao dos valores de campos constituintes da chave primria ou a remoo de uma entidade de um conjunto- entidade pode ocasionar problemas de integridade referencial. 17
13 Auto-Relacionamento
Um auto-relacionamento acontece quando os elementos de uma entidade se relacionam com eles mesmos. Ou seja, um item de uma entidade se relaciona com outro item (ou com o mesmo) dessa mesma entidade. Apesar de parecer algo difcil de acontecer h casos, bem comuns, que identificam este tipo de relao. Por exemplo, uma ocorrncia da entidade Funcionrio, Gerencia e Gerenciada por si prpria. Assim se d, ainda, na classe Militar em que o Oficial um Soldado. Este auto-relacionamento tambm conhecido como RELACIONAMENTO RECURSIVO ou RECURSIVIDADE. Um fator importante a ser observado que as relaes entre os elementos pode ser 1:N ou N:N, e possui as mesmas caractersticas de um relacionamento binrio (relao entre duas entidades). O relacionamento recursivo deve ser, sempre, entendido e representado nos dois sentidos (EMPREGADO GERENCIA e GERENCIADO) A implementao de um auto-relacionamento, atravs de um SQL, feita da seguinte forma (considere que a tabela FUNCIONARIO pr-existente e o EMPREGADO foi promovido a GERENTE): Julho de 2009
alter table FUNCIONARIO add constraint EMPR_EMPR_FK foreign key (GERENTE) references FUNCIONARIO (EMPREGADO); Note que a constraint EMPR_EMPR_FK relaciona a coluna GERENTE como uma chave estrangeira (Foreign Key) da coluna EMPREGADO na tabela FUNCIONARIO1
17
14 Agregao
Uma limitao do MER no poder expressar relacionamentos entre relacionamentos. Agregao uma abstrao atravs da qual os relacionamentos so tratados como entidades de nvel superior. Abaixo se observa a existncia de dois relacionamentos distintos entre as entidades FUNCIONARIO e PROJETO.
17
2
17
Apesar de parecer assustador, a soluo simples e possibilita uma leitura mais clara do novo diagrama que ser desenhado Aps a agregao, uma nova entidade (que pode ser rotulada/nomeada) representada contendo as entidades FUNCIONARIO-TRABALHA-PROJETO.
Com esta soluo, a limitao inicial de no poder relacionar TRABALHA e UTILIZA ficou facilmente resolvida. Julho de 2009
15 Generalizao Especializao
Existem casos em que uma entidade pode ser dividida em categorias, possuindo alm dos atributos comuns, alguns especficos para cada categoria. Por exemplo, considerando a entidade MDICO, pode-se atestar que todos os mdicos so, basicamente, clnicos gerais, mas cada um possui uma especialidade prpria como cardiologista, pneumologista, etc. A essa classificao (ou particionamento) d-se o nome de especializao, que nada mais do que a identificao de uma caracterstica prpria de objetos com propriedades similares.
17 1
17
Dentro deste modelo pode-se, ainda, considerar a existncia de outros tipos de especializao
16.2 No-Exclusiva
Julho de 2009
alvaro_pimentel@uol.com.br
16.3 Mltipla
17
1 N CONTRATA FUNCIONRIO 1 N CRIA DEPENDENTES
alvaro_pimentel@uol.com.br
17
NOTA: Todos os tipos de especializaes indicam que a entidade resultante herdar caractersticas da entidade origem. Desta maneira, ao resultado apresentado, diz-se que este possui uma HERANA, cujo conceito faz parte da ORIENTAO A OBJETO. Assim sendo, correto afirmar que, nos itens anteriores, h HERANA TOTAL, PARCIAL, NOEXCLUSIVA e MLTIPLA.
DEPARTAMENTO
Uma entidade fraca no possui uma identidade prpria. Assim sendo, sua chave primria composta pela chave estrangeira proveniente da entidade origem concatenada a um identificador de si mesma (que pode repetir para diferentes instncias da entidade dona).
Julho de 2009
FUNCIONRIO
FORNECEDOR
FORNECE
PROJETO
17
PEA
CODPEA
FORNECEDOR
FORNECE
PROJETO
PODE FORNECER
PEA
USA
Julho de 2009
CODPEA
alvaro_pimentel@uol.com.br
PARTE 1
17
PARTE 3
CORDFORN
QUANTIDADE
CODPROJ
17
FORNECE PROJETO PEA CODPEA
alvaro_pimentel@uol.com.br
FORNECEDOR
17
UM POUCO MAIS SOBRE CHAVES Uma chave chamada de primria (primary key pk) quando um atributo dado nico e obrigatrio em uma tabela. Por exemplo, tomando-se como base o CODFORN da tabela FORNECEDOR acima fcil observar que se trata de um atributo que representa um nico fornecedor, tal como o CGC. No caso de uma tabela PESSOA poderia ser o CPF, o RG ou a Carteira de Habilitao. Nota-se, ento, que a escolha de uma chave deve significar um atributo que no possua elementos que impossibilitem, ou minimizem erros de digitao. Portanto, no se deve escolher como chave atributos que contenham tamanhos variveis ou com formatos alfanumricos tal como nome, endereo ou descrio, por exemplo. Quando h a existncia de um relacionamento de uma entidade forte com uma fraca, obrigatoriamente a chave da tabela forte includa na fraca. Essa chave na tabela fraca chamada de chave estrangeira (foreign key fk) como ocorre nos relacionamentos um-para-muitos (1:N). Quando se trata, porm, de um relacionamento muitos-para-muitos (N:N) necessria a criao de uma tabela associativa que, neste caso, ser a entidade fraca. Assim, nesta nova entidade sero colocadas, como chaves estrangeiras (fk), as chaves primrias (pk) das tabelas de origem. A colocao de uma chave estrangeira sempre um indicativo de que uma entidade dependente de outra por uma razo qualquer. Os motivos que determinam a necessidade de criao de uma chave (quer seja pk ou fk) esto, na maioria das vezes, associados a regras de negcio identificadas no levantamento dos requisitos. Em outros casos so para resolver problemas de performance que so identificados aps a implementao das bases de dados ou dos sistemas. Portanto, as chaves sempre esto associadas a melhorias de acesso a base de dados.
Julho de 2009
19 Exerccios
19.1: Modele o relacionamento entre um Lote e um Produto considerando que o Produto refere-se a materiais de farmcia e pode ser subdividido em, pelo menos, duas entidades. Crie os atributos que considerar pertinente assim como as cardinalidades apropriadas. 19.2: Especialize a entidade Veculo em, pelo menos, seis entidades relacionadas. 19.3: Modele o relacionamento entre Empregado e Departamento considerando que o empregado pode ser dividido em Gerente, Secretria e Engenheiro. Para cada relacionamento do DER defina atributos quando possvel. Defina os atributos identificadores ou chaves 19.4: Considere agora que a secretria, do exerccio 3, use um Aplicativo que pode ser subdividido em trs itens. O Engenheiro participa de um Projeto, e ambos utilizam a entidade Mquina 19.5: Do exerccio 4 considere que um Fornecedor se relaciona com um Lote e com um Fabricante. Este, por sua vez, est relacionado com o Produto. Efetue a alterao no modelo para que ele atenda aos novos requisitos. 19.6: Uma empresa desenvolve projetos de grande porte. Esta empresa est organizada em departamentos, sendo que cada projeto sempre coordenado por um departamento. Os departamentos possuem empregados que podem ser chefes. Embora um empregado pertena sempre a um departamento, ele pode ser alocado a projetos de outros departamentos. Os funcionrios possuem nome, data de nascimento e cpf. Os responsveis pelo projeto so os chefes de departamento ao qual o projeto est alocado. Todo projeto possui uma rea (engenharia, urbanismo, etc.) e perodo definido de tempo. 19.7: De acordo com o DER abaixo um Analista ou Mdico no podem ser gerentes. Por qu? Qual a alterao necessria para tornar isso possvel?
17
alvaro_pimentel@uol.com.br
Julho de 2009
17
19.8: Uma organizao que atua no ramo de vendas de materiais de construo deseja montar um banco de dados para emisso de faturas em suas lojas, gerenciando a comisso de cada empregado. Sabe-se que: a) A empresa possui diversas lojas; b) Um empregado pertence sempre a uma loja; c) Uma nota fiscal composta de dados genricos (nmero da nota fiscal, nome do cliente, data de emisso, valor total da Nota fiscal, nome do empregado responsvel pela venda) e dados do detalhe da venda (nome do material vendido, quantidade deste material, valor unitrio, valor total do item de material vendido). . 17
17 1
Julho de 2009
alvaro_pimentel@uol.com.br
20 Normalizao3
O processo de normalizao pode ser visto como o processo no qual so eliminados esquemas de relaes (tabelas) no satisfatrios, decompondo-os, atravs da separao de seus atributos em esquemas de relaes menos complexas, mas que satisfaam as propriedades desejadas. Por que Normalizar ? 1) Minimizar de redundncias e inconsistncias; 2) Facilitar manipulaes do Banco de Dados; 3) Facilitar manuteno do Sistema de Informaes O processo de normalizao como foi proposto inicialmente por Codd conduz um esquema de relao atravs de uma bateria de testes para certificar se o mesmo est na 1, 2 e 3 Formas Normais. Para que se compreenda melhor suponha que haja uma entidade Funcionrios que armazene as informaes dos funcionrios de uma empresa e que o resultado fsico final seja a tabela mostrada abaixo. 1
17
Ao se observar a tabela v-se que ela sofre das seguintes anomalias: Anomalia de Excluso Se o funcionrio de cdigo igual a 3 for excludo, o Setor ser excludo tambm. Anomalia de Alterao Se o nome do Setor Suporte mudar para Apoio ser obrigatrio a alterao, deste nome, em todos os registros da tabela. Anomalia de Incluso Se um novo funcionrio for contratado para o Setor Suporte ser obrigatria a alterao da quantidade de funcionrios no campo QuantidadeFuncionarios em todas as ocorrncias que houver o setor de nome SUPORTE.
Para poder resolver o dilema acima necessrio NORMALIZAR a entidade. Para isto aplica-se as formas normais como ser estudado a seguir:
Julho de 2009
Os conceitos de Normalizao e Formas Normais foram baseados na literatura disponibilizada no endereo http://leitejr.files.wordpress.com/2008/09/modelagem.pdf
alvaro_pimentel@uol.com.br
17
17
No normalizada Normalizada usando a primeira forma normal (1FN)
Julho de 2009
alvaro_pimentel@uol.com.br
Considerando-se, agora, as entidades: Arquivo de Notas Fiscais (Num. NF, Srie, Cdigo do Cliente, Nome do cliente, Endereo do cliente, Total Geral da Nota) Arquivo de Vendas (Num. NF, Cdigo da Mercadoria, Descrio da Mercadoria, Quantidade vendida, Preo de venda e Total da venda) O resultado aps a aplicao da segunda forma normal (2FN) ser: Arquivo de Notas Fiscais (Num. NF, Srie, Cdigo do Cliente, Nome do cliente, Endereo do cliente, Total Geral da Nota) 17 Arquivo de Vendas (Num. NF, Cdigo da Mercadoria, Quantidade vendida e Total da Venda) Arquivo de Mercadorias (Cdigo da Mercadoria, Descrio da Mercadoria, Preo de venda) 1
Como resultado nota-se um desdobramento do Arquivo de Vendas em duas estruturas Vendas e Mercadoria (o arquivo de Notas Fiscais, no foi alterado, por no possuir chave composta): Primeira estrutura (Arquivo de Vendas): Contm os elementos originais, sendo excludos os dados que so dependentes apenas do campo Cdigo da Mercadoria. Segunda 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.
Julho de 2009
alvaro_pimentel@uol.com.br
17
Estrutura na segunda forma normal (2FN): Arquivo de Notas Fiscais (Num. NF, Srie, Data emisso, Cdigo do Cliente, Nome do cliente, Endereo do cliente, 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) 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) Julho de 2009 Pode-se perceber que ocorreu um desdobramento da tabela de Notas Fiscais, por ser a nica que possua campos que no eram dependentes da chave principal (Num. NF). Os elementos Nome e Endereo no se alteram independente do que ocorra com a Nota Fiscal.
alvaro_pimentel@uol.com.br
17
21 Exerccios
21.1. Considerando a existncia de trs tabelas (FUNCIONRIO, DEPENDENTE, CURSO) normalize-as de acordo com o que foi desenvolvido FUNCIONRIO -MATRCULA DO FUNCIONRIO -NOME DO FUNCIONRIO -DATA DO NASCIMENTO CURSO -CDIGO DO CURSO -NOME DO CURSO -ANO DO CURSO 17 DEPENDENTE -CDIGO DO DEPENDENTE -NOME DO DEPENDENTE 1
Regras do negcio (RN): RN1. Um funcionrio pode ter mais de um dependente RN2. Um funcionrio pode fazer mais de um curso
21.2 Imagine que seja necessrio desenvolver um sistema para cadastro de clientes e foi recebida, do cliente, uma lista com os dados que devero compor o sistema, com base nela normalize a estrutura de dados de acordo com as formas normais estudadas. A ttulo de treinamento considere o tratamento das informaes como um pequeno dicionrio de dados, em que sero descritos os atributos pertinentes aos elementos. Lista de informaes que devero compor o sistema cadastro de clientes: Nome do dado Descrio Nome Nome do cliente pessoa fsica Nome do Pai Nome da Me Endereo Telefone1 Telefone2 Nmero do Fax Nmero do Celular Telefone do trabalho Data de Nascimento Naturalidade Nacionalidade Endereo correspondncia Nome do filho 1 idade do filho 1 Nome do filho 2 idade do filho 2 Nome do filho 3 idade do filho 3 Nome do filho 4 idade do filho 4 Nome do Cnjuge
alvaro_pimentel@uol.com.br
Julho de 2009
17
17
O Departamento de Vendas da Indstria Beleza Ltda, aps estudos de mercado, verificou que para atingir seus objetivos seria necessrio adquirir uma frota de veculos prprios para motorizar seus vendedores. O mercado consumidor foi dividido em regies de venda; foram estabelecidos percursos de entrega abrangendo pontos estratgicos dessas regies e vendedores foram designados para cobrir estes percursos. Deve ser construdo um sistema para administrao do novo modelo de vendas adotado pela empresa. Aps entrevistas com o gerente da rea, foram obtidas as seguintes informaes: - cada regio identificada por um cdigo; - uma regio composta de vrios pontos estratgicos; - as regies no tm pontos estratgicos em comum; - o vendedor tem a responsabilidade de cobrir uma regio; - uma regio pode ser coberta por vrios vendedores; - a cada dia, um veculo fica sob responsabilidade de um vendedor; - um vendedor pode vender quaisquer itens ativos da tabela de produtos; - o vendedor responsvel pela identificao de cada cliente consumidor na nota fiscal; - a nota fiscal contendo identificao do vendedor, itens e quantidades vendidas exigida para comprovao da venda
21.4 De acordo com as regras estudadas normalize as estruturas abaixo. Relao de Programadores: Numero da Matrcula Nome do Programador Setor Nvel ( 1,2,3) Descrio do Nvel ( 1 - Jnior, 2 - Pleno, 3 - Senior) Programas Codigo do Programa Nome do Programa Tempo Estimado Nvel de Dificuldade ( 1, 2 ou 3 ) Descrio da Dificuldade ( Fcil, Mdio, Difcil) Regras do negcio: - Um programa pode ser feito por mais de um Programador; - Um programador pode fazer um ou mais programas; - O Nvel de dificuldade do programa depende do tempo estimado para a elaborao do mesmo;
Julho de 2009
alvaro_pimentel@uol.com.br
17
22 Solues
As respostas apresentadas representam apenas uma das solues possveis. Em se tratando de modelagem de dados o caso certo o que atende a uma especificao dentro dos padres estabelecidos. Em muitos casos necessrio desnormalizar um modelo para melhorar o acesso a uma base e, com isso, melhorar a performance do processo de busca. Uma soluo do 12.1:
17
alvaro_pimentel@uol.com.br
17
As solues 12.1, 12.2 e 12.5 representam um modelo que no contempla os conceitos de normalizao, entretanto, como treinamento inicial, importante entender como se constri um relacionamento e de que maneira pode-se, ento, melhorar o particionamento dos dados Uma soluo do 12.2:
Uma soluo do 12.3: TABELA CLIENTE (CdCli (pk), NnCli, EnCli) TABELA BANCO(CdBnc (pk), NmBnc, EnBnc) Uma soluo do 12.4:
Julho de 2009
17
alvaro_pimentel@uol.com.br
17
Julho de 2009
17
alvaro_pimentel@uol.com.br
17
Julho de 2009
17
alvaro_pimentel@uol.com.br
17
Julho de 2009
17
alvaro_pimentel@uol.com.br
17
Julho de 2009
17 Julho de 2009 17
alvaro_pimentel@uol.com.br
O modelos abaixo foram desenvolvidos no software gratuito MySQL Workbench Uma soluo do 21.1:
17 1
17
Como foi explicado no tpico 12.3, toda vez que for identificado um relacionamento n:n sempre ser necessria a criao de um tabela extra para representar o relacionamento. Neste caso um a funcionrio pode se inscrever em muitos (n) cursos e, por sua vez um curso pode possuir muitos (n) funcionrios. Assim, foi criada tabela associativa (ou juno) Curso do Funcionrio para evitar a redundncia de dados nas tabelas origens.
Julho de 2009
alvaro_pimentel@uol.com.br
17
alvaro_pimentel@uol.com.br
17
Atualmente j possvel, legalmente, um indivduo possuir pais de mesmo sexo. Por esta razo, a Filiao uma tabela associativa (que representa a paternidade/maternidade) de Tutor com a tabela Cliente. Talvez fosse interessante criar uma tabela que identificasse o tipo do dependente, o tipo do telefone e o tipo do endereo. No entanto a diviso dessas tabelas pode influenciar em um esforo extra considerando os valores que podem ser assumidos por elas.
Julho de 2009
17 17 A tabela Uso Veculo representa uma juno dos veculos que podem ser utilizados pelos vendedores. importante notar que sua existncia s acontecer se as tabelas pai existirem. Julho de 2009
alvaro_pimentel@uol.com.br
17 17 A tabela Programador Programa associativa pelas mesmas razes apresentadas nas solues anteriores. possvel que sejam encontradas solues melhores que as apresentadas anteriormente. Cabe lembrar que modelagem de dados como a construo de conhecimento que vai se edificando com o tempo. Raramente se constri uma modelagem que no sofra alteraes, ou que no contenha equvocos, e isso faz parte do processo de desenvolvimento de um modelo de bases de dados. Exercitar o que vai trazer experincia e mais habilidade no tratamento dos dados. No prximo manual ser tratada a instalao, a modelagem e o manuseio de uma base de dados MySQL atravs da ferramenta CASE MySQL Workbench e MySQL Query Browser. Julho de 2009 A instalao do MySQL est na apostila Free Acess: O MySQL na prtica disponvel no endereo http://artigocientifico.tebas.kinghost.net/pesquisadores/?mnu=2&smnu=5&id=29536
Alvaro Caetano Pimentel Sobrinho Doutorando em Cincia da Informao UFRJ/IBICT, Mestre em Tecnologia da Informao UNESA, Formado em Telecomunicaes UNESA, Administrador de bases de dados Oracle, Db2 e Idms e
alvaro_pimentel@uol.com.br
17
Julho de 2009
17
alvaro_pimentel@uol.com.br