You are on page 1of 17

MINISTRIO DA EDUCAO

SECRETARIA DE EDUCAO PROFISSIONAL E TECNOLGICA


INSTITUTO FEDERAL FARROUPILHA
CAMPUS SO BORJA
BACHARELADO EM SISTEMAS DE INFORMAO
THIAGO STOLL, AMANDA, PAULA, JOO, NATIELE, DIEGO
DESENVOLVIMENTO DO BANCO DE DADOS PARA UMA CORRETORA DE
SEGUROS
SO BORJA
2014
2
2



























THIAGO STOLL, AMANADA, PAULA, JOO, NATIELE, DIEGO

DESENVOLVIMENTO DO BANCO DE DADOS PARA UMA CORRETORA
DE SEGUROS

Relatrio apresentado referente ao
desenvolvimento de um de projeto banco de
dados que atenda a demande de uma corretora
de seguros, propriedade intelectual dos alunos
do curso de Bacharelado em Sistemas de
Informao do Instituto Federal Farroupilha
Campus So Borja.


MINISTRIO DA EDUCAO
SECRETARIA DE EDUCAO PROFISSIONAL E TECNOLGICA
INSTITUTO FEDERAL FARROUPILHA
CAMPUS SO BORJA
BACHARELADO EM SISTEMAS DE INFORMAO
SO BORJA
2014
2
3

SUMRIO



INTRODUAO 05

1. BANCO DE DADOS 07
1.1. Reconhecimento do problema e definio do modelo de dados 08
1.2. Modelo conceitual 09
1.3. Modelo lgico 10
1.4. Definio estrutural das tabelas do esquema 12
1.5. Definio da modelagem lgica do projeto 15


CONCLUSO 16

REFERNCIAS 17



4

LISTA DE FIGURAS

Figura 1. Modelo conceitual Corretora de seguros..........................................09
Figura 2. SGBD MYSQL Workbench..................................................................15







5

INTRODUO
Com o avano tecnolgico, surgem novas formas de armazenar dados e de
organizao dos mesmos, necessrio o armazenamento tanto de dados de
pessoas fsicas, quanto dados de entidades e empresas, muitos softwares que
realizam tal funo j esto no mercado h bastante tempo, porm muitas vezes no
possuem a estrutura interna (organizao de banco de dados) que o cliente espera.
Por esse motivo tem crescido cada vez mais a procura por softwares personalizados
onde o cliente define os pr-requisitos e ele acompanha todo o desenvolvimento do
programa, desta forma tendo uma participao ativa com a empresa e alcanando o
objetivo e a qualidade que se espera de um software criado especificamente para
uma funo ou determinada rea de atuao. Conforme o entendimento de Heuser
a definio de um banco de dados consiste em:
Banco de dados = Conjunto de dados integrados que tem por objetivo
atender a uma comunidade de usurios. uma coleo de dados
organizados contendo informaes relevantes para um grupo de usurios
ou conjunto de aplicaes.(Heuser, 2009, p.22)

Muitas vezes o desenvolvimento de um software utilizando os mtodos
tradicionais em tempo normal demora mais que o esperado por um cliente, tendo
seu tempo mdio de desenvolvimento entre trs e seis meses, dependendo de sua
complexidade, do mtodo utilizado, do nmero e empenho dos participantes da
equipe no projeto. Partindo deste tempo de desenvolvimento o contato com o cliente
feito somente no inicio do projeto para o levantamento dos pr-requisitos desta
forma o cliente muitas vezes acaba reformulando sua ideia de um software ideal.
Vem deste principio, a importncia do acompanhamento do cliente em todas as
etapas do programa, pois assim ele sabe exatamente como est sendo construdo,
podendo auxiliar os programadores e desenvolvedores em seus questionamentos
para que haja somente bons resultados ao final do desenvolvimento.
Presentemente por menor e mais simples que seja o software desenvolvido
ele necessitar de uma base de dados, onde a partir da seja possvel armazenar e
recuperar dados com uma velocidade considervel. Para esses fins os
desenvolvedores utilizam programas conhecidos com SGBDs ou ainda Sistemas
Gerenciadores de Bancos de Dados.
6

Neste projeto pensou-se em facilitar e automatizar o funcionamento de uma
corretora de seguros, ento comeou-se a desenvolver uma base de dados para
empresas que prestam este servio, desta forma aps criado o problema, ou como
sabemos, mini mundo, seguiu-se por todas as etapas que um banco de dados
consistente deve seguir em seu desenvolvimento para que assim fosse possvel
obter uma base de dados o mais correta possvel, tem-se que de acordo com
Angelotti:
A importncia de uma boa modelagem se deve ao fato de que as
aplicaes que estaro acessando a base de dados deves estar em
consonncia com o modelo desenvolvido(Angelotti, 2010, p.15)













7

BANCO DE DADOS
Dados so todas as informaes que podem-se inferir ou coletar sobre uma
situao especifica, pode ser desde as informaes mais simples como por exemplo
a cor de uma casa, ou o numero de quartos desta casa, ou ainda informaes mais
complexas como a movimentao da conta bancaria de uma empresa. A partir
desses simples conceitos surge ento a definio de banco de dados, muito utilizada
na informtica, pois todo e qualquer software possui sua prpria base de dados a
qual retira grande parte das informaes necessria para que seja possvel sua
execuo e bom funcionamento. Segundo o entendimento de Angelotti uma base de
dados tem por definio:
[...] um local, ou espao, onde informaes esto armazenadas e de
onde elas so recuperadas. Uma base de dados ter um nome, e este
nome dever oque aquela base armazena. Essa base de dados dever
todas as informaes que forem solicitadas. Essa base permite que os
dados fiquem centralizados e que se relacionem de forma coerente [...].
(Angelotti, 2010, p.10)

Tem-se tambm alm da base de dados o Sistema de Banco de Dados, o
qual se trata de uma ferramenta utilizada para armazenar informaes, a mesma
tem trs principais funcionalidades, armazenar dados, relacion-los, e recuper-los
rapidamente, importante ressaltar que armazenar dados e no relaciona-los no
nem um pouco interessante para que desenvolve um Sistema de Informao. Sabe-
se que toda tecnologia tende a evoluo, com os Sistemas de Banco de Dados no
diferente, surge ento os Sistemas Gerenciadores de Banco de Dados (SGBD).
O SGBD trata-se de uma ferramenta muito mais completa e funcional que o
antecessor Sistema de Banco de Dados, pois ele disponibiliza ao desenvolvedor
uma srie de funcionalidades que o permite acompanhar e controlar de maneira
mais prtica os dados armazenados no sistema. Heuser define o SGBD da seguinte
forma:
Sistema de gerencia de banco de dados (SGBD) = Software que incorpora
as funes de definio, recuperao e alterao de dados de um banco de
dados. (Heuser, 2009, p.23)



8

1.1. Reconhecimento do problema e definio do modelo de dados
Em consenso ao grupo aps discutir vrias sugestes de projeto, pensou-se
ento no desenvolvimento de um banco de dados para a utilizao de uma corretora
de seguros, com objetivo principal em tornar este sistema confivel, eficaz, e pratico.
Iniciou-se ento o desenvolvimento da problemtica por partes, ou, mini mundo
termo o qual o chamamos na informtica, ou ainda modelo de dados. Ainda segundo
Heuser (2009) modelo de dados uma descrio formal da estrutura de um banco
de dados.
No modelo de dados definiu-se ento o relato a seguir:
- BANCO DE DADOS DE UMA CORRETORA DE SEGUROS
Dever atender uma corretora de seguros com um sistema on-line, onde deve
ser possvel:
Possuir um cadastro de clientes, com os seguintes atributos: cdigo,
nome, telefone, endereo, e-mail se o cliente for do tipo pessoa fsica
dever conter os seguintes atributos: rg, cpf, data de nascimento, n de
dependentes. Se caso o cliente for do tipo pessoa jurdica deve conter os
seguintes atributos: cnpj, scio, inscrio estadual;
Na entidade de dependentes dever conter: sexo, idade, nome;
Na entidade funcionrio deve conter: cdigo, cpf, nome, email, telefone,
carga horaria, salrio;
Na entidade estagirio, que ser uma especialidade da entidade
funcionrio, deve conter: agente integrador, contrato;
Na entidade celetista, que dever conter: ctps, endereo;
Plano de seguro de veculo: placa, ano, modelo, cor, chassi, cpf do
proprietrio, valor do veculo, valor seguro do veiculo, pessoa autorizada;
Plano de sade: valor do plano, carncia, data de pagamento, data de
vigncia;
Seguro de vida: valor parcela mensal, carncia, valor da aplice;
Corretor nome, susep, cpf, telefone, endereo, e-mail;
9

1.2. Modelo conceitual
O modelo conceitual de um banco de dados trata-se da descrio do mesmo
independentemente de implementao alguma, refere-se ao desenvolvimento de um
modelo inicial da base de dados que reflita as necessidades do usurio, o modelo
conceitual tem por finalidade registrar quais dados sero denotados no banco de
dados, porm no especifica os tidos desses dados e nem como sero
implementados no SGBD. Heuser (2009) define a modelagem conceitual como um
modelo de dados abstrato que descreve a estrutura de uma banco de dados de
forma que independe de um SGBD particular como escrito anteriormente.
O desenvolvimento do modelo conceitual referente ao sistema para a
corretora de seguros foi elaborado com base principal em seu modelo de dados
onde l foram definidos suas entidades e atributos principais. A figura 1 apresenta o
desenvolvimento deste modelo conceitual.
Figura 1: Modelo conceitual Corretora de seguros.
10

1.3. Modelo lgico
O modelo lgico trata-se de uma descrio dos dados em um nvel de
abstrao e detalhamento ao quais os usurios (desenvolvedores) do SGBD tero
maior facilidade de entendimento, desta forma, contrariando o modelo conceitual o
modelo logico depende sim do SGBD, pois est sendo direcionado para ele. Em
concordncia com Heuser (2009), modelo lgico pode ser definido resumidamente
como o modelo de dados que representa a estrutura de dados de um banco de
dados conforme vista pelo usurio do SGBD, desta forma este modelo deve definir
quais tabelas o banco de dados deve conter e consequentemente quais as colunas
que essas tabelas devem dispor.
A seguir encontra-se o modelo logico do banco de dados em desenvolvimento
da corretora de seguros, este modelo foi elaborado dispondo como base todo
processo anterior, passando pela converso desde o problema at a notao
relacional, sendo ento uma sequencia de desenvolvimento deste banco de dados.

Notao relacional
tbCliente ( ID:inteiro,nome:caractere, telefone:caractere,
email:caractere, endereo:caractere)

tbPessoaF ( CPF:caractere,*ID_cliente:inteiro, sexo:caractere,
RG:caractere)
ID_cliente referencia tbCliente

tbPessoaJ (CNPJ:inteiro,*ID_cliente:inteiro,
inscricaoestadual:caractere, numero_beneficiarios:inteiro)
ID_cliente referencia tbCliente

tbDependentes(*ID_cliente:inteiro, nome:caractere, data_nasc:data,
sexo:caractere)
ID_cliente referencia tbCliente

tbFuncionario(ID:inteiro,*ID_representante:inteiro, nome:caractere,
telefone:caractere, email:caractere, carga_horaria:hora,
salrio:decimal(6,2))
ID_representante referencia tbFuncionario

tbCeletista(*ID_funcionario:inteiro, PIS:inteiro, ctps:caractere,
hora_extra:hora)
ID_funcionario referencia tbFuncionario

11

tbEstagiario(*ID_funcionario:inteiro,
agente_integrador:caracter,curso:caractere,
instituio_ens:caractere,num_contrato:inteiro)
ID_funcionario referencia tbFuncionario
tbSeguroVida (ID_seguro:inteiro,*SUSEP:caractere,
valor_plano:decimal(100,2), valor_apolice:decimal(100,2),
carencia:caractere)
SUSEP referencia tbCorretor

tbVenda(*ID_funcionario:inteiro, *ID_cliente:inteiro,
*ID_seguro:inteiro, valor_venda:decimal(1000,2),
data_venda:decimal(1000,2), comisso:decimal(1000,2))
ID_funcionrio referencia tbFuncionrio
ID_cliente referencia tbCliente
ID_seguro referencia tbSeguroVida

tbCorretor(CPF:inteiro, nome:caractere, SUSEP:caractere,
email:caractere, telefone:caractere)

tbPlano_saude(ID:inteiro, data_pag:data,carncia:caractere,
valor_plano:decimal(1000,2), data_vigencia:data)

tbValidacao(*ID_planoSaude:inteiro, *ID_cpf_corretor:caractere,
valida:logico)
ID_planoSaude referencia tbPlano_saude
ID_cpf_corretor referencia tbCorretor

12

1.4. Definio estrutural das tabelas do esquema

cliente
chave atributo tipo tamanho obrigatorio restries
PK id_cliente inteiro sim nico
nome caractere 45 sim
telefone caractere 45 no
email caractere 45 no


tbPessoF
chave atributo tipo tamanho obrigatorio restries
PK cpf caractere 45 sim nico
FK id_cliente int sim
integridade referencial
com a tabela Cliente
sexo caractere 45 sim
RG caractere 45 sim


tbPessoaJ
chave atributo tipo tamanho obrigatorio restries
PK cnpj inteiro sim nico
FK id_cliente inteiro sim
integridade referencial
com a tabela Cliente
inscricaoEstadual caractere 45 sim nico


tbDependente
chave atributo tipo tamanho obrigatorio restries
PK, FK id_cliente inteiro sim
integridade referencial
com a tabela Cliente
nome caractere 45 sim
data_nasc data sim
sexo caractere 45 sim


tbFuncionario
chave atributo tipo tamanho obrigatorio restries
PK id inteiro sim nico
FK id_representante inteiro sim
integridade referencial
com a tabela
tbFuncionario
nome caractere 45 sim
telefone caractere 45
email caractere 45
carga_horaria data sim
salario decimal 6,2 sim


13

tbCeletista
chave atributo tipo tamanho obrigatorio restries
PK,FK id_funcionario inteiro sim
integridade referencial
com a tabela
tbFuncionario
pis inteiro sim
ctps caractere 45 sim
hora_extra data


tbEstagiario
chave atributo tipo tamanho obrigatorio restries
PK,FK id_funcionario inteiro sim
integridade referencial
com a tabela
tbFuncionario
agente_integrador caractere 45 sim
curso caractere 45 sim
instituicao_ensino caractere 45 sim
num_contrato inteiro sim


tbSeguroVida
chave atributo tipo tamanho obrigatorio restries
PK id_seguro inteiro sim
FK susep caractere sim
integridade referencial
com a tabela tbCorretor
valor_plano decimal 100,2 sim
valor_apolice decimal 1000,2 sim
carencia data sim


tbVenda
chave atributo tipo tamanho obrigatorio restries
PK,FK id_funcionario inteiro sim
integridade referencial
com a tabela
tbFuncionario
PK,FK id_cliente inteiro sim
integridade referencial
com a tabela tbCliente
PK,FK id_seguro inteiro sim
integridade referencial
com a tabela tbSeguroVida
valor_venda decimal 1000,2 sim
data_venda data sim
comissao decimal 1000,2 sim


tbCorretor
chave atributo tipo tamanho obrigatorio restries
PK cpf inteiro sim
nome caractere 45 sim
14

susep caractere 45 sim nico
email caractere 45 sim
telefone caractere 45 sim


tbPlano_saude
chave atributo tipo tamanho obrigatorio restries
PK id_plano inteiro sim
data_pag data sim
carencia caractere 45 sim
valor_plano decimal 1000,2 sim
data_vigencia data sim


tbValidacao
chave atributo tipo tamanho obrigatorio restries
PK,FK ID_plano_saude inteiro sim
integridade referencial
com a tabela
tbPlano_saude
PK,FK ID_cpf_corretor inteiro sim
integridade referencial
com a tabela tbCorretor



15

1.5. Definio da modelagem lgica do projeto

Aps o processo de passagem pelo modelo lgico do banco de dados da
corretora de seguros, pensou-se ento por implementa-lo usando algum SGBD,
optou-se ento pela implementao utilizando a ferramenta MYSQL Workbench,
pois j possuamos uma afinidade com a mesma. As tabelas criadas no SGBD
foram a seguintes: Corretor, Veiculo, Validao, Plano de sade, Endereo, Cliente,
Pessoa fsica e pessoa jurdica, Dependentes, plano de sade cliente funcionrio (
vindo da unio de trs tabelas), seguro de vida, venda. Funcionrio, celetista, e por
fim estagirio.
A seguir est representado na figura 2 o banco de dados no SGBD MYSQL
Workbench.
Figura 1: SGBD MYSQL Workbench.



16

CONCLUSO

Aps o termino do projeto foi possvel perceber a tamanha importncia de
uma modelagem que atenda o mais prximo possvel do problema real apresentado,
com isso o aprendizado do grupo foi atravs das vrias etapas necessrias para a
execuo de um planejamento de sistema de banco de dados. Atravs do
conhecimento aplicado atravs do modelo proposto, podemos melhorar a
capacidade de percepo da construo de um modelo de projeto de banco de
dados, assim utilizando ferramentas necessria e conhecimentos vivenciados em
sala de aula para uma melhor experincia.

17

REFERNCIAS

ANGELOTTI, Elaini Simoni. Banco de dados/ Elaini Simoni Angelotti - Curitiba:
Editora do livro Tcnico, 2010, 120 pginas.

HEUSER, Carlos Alberto. Projeto de banco de dados / Carlos Alberto Helser. 6.
Ed. Porto Alegre : Bookman, 2009, 283 pginas.

SOMMERVILLE, Ian. Engenharia de software. 8 ed. / Ian Sommerville; So Paulo:
Pearson Addison Wesley, 2007, 304 pginas.

You might also like