Modelo Conceitual de Dados
Existem várias metodologias disponíveis para a concepção de modelos de banco de dados. Cada uma destas abordagens diferentes consiste de uma série de etapas. Um banco de dados pode ser desenhado por um único indivíduo ou uma equipe de analistas.
Análise de requisitos: Coleta informações sobre a natureza dos dados, recursos necessários e eventuais necessidades especializadas, como respostas de saída esperados. Esta etapa abrange o que é necessário, portanto, basta analisar e anotá-la. Fale com os funcionários e clientes da empresa para ter uma melhor ideia do que exatamente precisam.
Projeto Conceitual: É onde você começa a usar as ferramentas gráficas para desenhar os Diagramas Entidade-Relacionamento (DERs). Esta etapa inclui a criação de tabelas, campos dentro dessas tabelas, e os relacionamentos entre as tabelas. Este passo também inclui a normalização.
Projeto lógico: Cria comandos da linguagem de banco de dados para gerar as definições da tabela. Algumas ferramentas usadas para criar DERs permitem a geração de dados de definição de linguagem (DDL) script, porém, que são susceptíveis de gerar scripts genéricos.
Projeto físico: Ajusta os comandos da linguagem de banco de dados para alterar o modelo de banco de dados para os atributos físicos subjacentes de tabelas. Por exemplo, você pode querer armazenar objetos binários grandes em arquivos separados, subjacentes ao do padrão relacional registro de campo de dados.
Fase de ajuste (tuning): Inclui itens como a indexação adequada, uma maior normalização, ou mesmo desnormalização, recursos de segurança, e qualquer outra coisa não é coberta pelas etapas anteriores.
O modelo conceitual de dados tem sido mais bem sucedido como uma ferramenta de comunicação entre analista e o usuário final durante as fases de análise de requisitos e projeto lógico. Seu sucesso se deve ao fato que o modelo, usando ER ou UML, é fácil de entender a conveniente para representar. Outra razão para sua eficácia é que é uma abordagem top-down utilizando o conceito de abstração. O número de entidade em um banco de dados é tipicamente muito menor que o número de elementos de dados individuais porque elementos de dados geralmente representam os atributos. Portanto, usar entidades como uma abstração dos elementos de dados e focar os relacionamentos entre entidades reduz significativamente o número de objetos em análise e simplifica a análise. Embora ainda seja necessário representar elementos de dados por atributos de entidades no nível conceitual, suas dependências são normalmente restringidas aos outros atributos dentro da entidade ou, em alguns casos, para atributos associados com outras entidades com um relacionamento direto com a sua entidade.
As principais dependência inter-atributos que ocorrem em modelos de dados são as dependências entre as entidades chaves, os identificadores únicos de diferentes entidades que são capturados no processo de modelagem conceitual de dados. Casos especiais, como dependências entre elementos de dados de entidades não relacionadas, podem ser manuseados quando eles são identificados na análise de dados que se seguiu.
Visão conceitual
O tipo, tamanho ou finalidade do banco de dados é totalmente irrelevante para o valor da realização de um projeto totalmente desenvolvido. Você deve implementar e acompanhar o processo de design de banco de dados, do início ao fim.
O nível de integridade estrutural e integridade dos dados em seu banco de dados é diretamente proporcional ao quão completamente você seguir o processo de design. Quanto menos tempo você gasta no processo de design, maior o risco que se corre de se deparar com problemas no banco de dados. Embora o processo de design de banco de dados pode não eliminar todos os problemas que podem ocorrer ao projetar um banco de dados, ele vai ajudar muito a minimizá-los.
A primeira fase no processo de design de banco de dados envolve a definição de uma declaração de missão (o propósito do banco de dados) e objetivos da missão (as tarefas gerais que os usuários podem realizar com os dados no banco de dados) do banco de dados.
Identificar a finalidade do banco de dados e defini-la dentro de uma declaração de missão ajuda a garantir que você desenvolva uma estrutura de banco de dados apropriado e que você coletará os dados necessários para suportar a finalidade do banco de dados. Definir os objetivos da missão apoia a sua declaração de missão e ajuda a determinar vários aspectos da estrutura de banco de dados.
O desenvolvedor de banco de dados, o proprietário ou diretor da organização, e gestor de pessoal, são responsáveis pela definição da missão. O desenvolvedor de banco de dados, gestor de pessoal, e os usuários finais, serão responsáveis pela definição dos objetivos da missão.
Dependendo da organização, o banco de dados será tipicamente um banco de dados legado (banco de dados herdado) ou um banco de dados baseado em papel. Um banco de dados legado é um que já existe e está em uso. Um banco de dados baseado em papel é um conjunto disperso de formulários, fichas, pastas, e assim por diante. Seja qual for o tipo de banco de dados ou condição, analisá-lo fornecerá informações valiosas sobre a forma como a organização está usando no momento e gerenciando seus
dados. Além disso, a análise envolve a revisão da forma como a organização coleta e apresenta os dados.
Modelo conceitual de dados
Considere as subetapas no modelo conceitual de dados usando o modelo ER: Classificar as entidades e atributos (classificar classes e atributos em UML). Identificar as hierarquias de generalização (para ambos modelos ER e UML). Definir relacionamentos (definir associações e associações de classes em UML).
Classificar entidades e atributos
As seguintes diretrizes para classificar entidades e atributos ajudarão os pensamentos do analista convergir para um projeto de banco de dados relacional normalizado:
Entidades devem conter informação descritiva.
Atributos multivalorados devem ser classificados como entidades.
Atributos devem ser anexados às entidades que mais diretamente os descrevem.
Conteúdos das entidades
Entidades devem conter informações descritivas. Se há informação descritiva sobre um elemento de dado, o elemento de dado deve ser classificado como uma entidade. Se um elemento de dado requer somente um identificador a não tem relacionamentos, deve ser classificado como um atributo. Com cidade, por exemplo, se há alguma informação descritiva como país e população para cidades, então cidade deve ser classificada como uma entidade. Se somente o nome da cidade é necessário para identificar uma cidade, então cidade deve ser classificada como um atributo associado com alguma entidade, como Projeto. Exemplos de outros elementos de dados no mundo real que são tipicamente classificadas como entidades incluem Funcionário, Cargo, Projeto, Departamento, Companhia, Cliente, e assim por diante.
Atributos multivalorados
Um atributo multivalorado de uma entidade é um atributo que pode ter mais que um valor associado com a chave da entidade. Por exemplo, uma grande empresa pode ter muitas divisões, algumas delas possivelmente em diferentes cidades. Nesse caso, divisão ou NM_DIVISAO deve ser classificada como um atributo multivalorado da entidade Empresa (e sua chave, ID_EMPRESA). O atributo NM_ENDERECO_SEDE_COMPANHIA, por outro lado, normalmente seria um atributo de valor único.
Nesse exemplo, o atributo multivalorado NM_DIVISAO deve ser reclassificado como uma entidade Divisão com ID_DIVISAO como seu identificador (chave) e NM_ENDERECO_DIVISAO como um atributo descritor.
Atributo anexo
Anexar atributos a entidades que mais diretamente os descrevem. Por exemplo, o atributo NM_EDIFICIO_ESCRITORIO deve normalmente ser um atributo da entidade Departamento, em vez da entidade Funcionário.
Identificar as hierarquias de generalização
Se há uma hierarquia de generalização entre entidades, então coloque o identificador e os descritores genéricos na entidade supertipo e coloque o mesmo identificador e descritores específicos nas entidades subtipos.
Por exemplo, suponha as cinco entidades que foram identificadas no modelo ER mostrado abaixo:
Funcionário, com identificador CD_FUNCIONARIO e descritores NM_FUNCIONARIO, NM_ENDERECO, DT_NASCIMENTO.
Gerente, com identificador CD_FUNCIONARIO e descritores NM_FUNCIONARIO e CD_CARGO.
Engenheiro, com identificador CD_FUNCIONARIO e descritores NM_FUNCIONARIO, CD_NIVEL_GRADUACAO e CD_CARGO.
Tecnico, com identificador CD_FUNCIONARIO e descritores NM_FUNCIONARIO e CD_ESPECIALIADADE.
Secretaria, com identificador CD_FUNCIONARIO e descritores NM_FUNCIONARIO e CD_MELHOR_HABILIDADE.
A entidade Funcionário poderia ser criada como uma generalização de Gerente, Engenheiro, Técnico e Secretária. Então nós colocamos o identificador CD_FUNCIONARIO e o descritor genérico NM_FUNCIONARIO, NM_ENDERECO, e DT_NASCIMENTO na entidade supertipo Funcionário; o identificador CD_FUNCIONARIO e o descritor específico CD_CARGO na entidade subtipo Gerente; identificador CD_FUNCIONARIO e descritor específico CD_NIVEL_GRADUACAO e CD_CARGO na entidade subtipo Engenheiro; etc. Mais tarde, se nós decidirmos eliminar Funcionario como uma entidade, os identificadores originais e atributos genéricos podem ser redistribuídos para todas as entidades subtipo.
Definir relacionamentos
Elementos de dados que representam associações entre entidades, nós chamamos relacionamentos. Exemplos de relacionamentos típicos são trabalha_em, trabalha_para, compra, dirige, ou qualquer verbo que conecte entidades. Para cada
relacionamento deve ser especificado o seguinte: grau (binário, ternário, etc.), conectividade (um-para-muitos, etc.), existência opcional ou obrigatória, e os atributos que são associados com o relacionamento e não com as entidades.
Relacionamentos redundantes
Analise relacionamentos redundantes cuidadosamente. Dois ou mais relacionamentos utilizados para represente o mesmo conceito são considerados redundantes. Relacionamentos redundantes tem mais probabilidade de resultar em tabelas desnormalizadas quando transformados no modelo ER em esquemas relacionais. Dois ou mais relacionamentos são permitidos entre as mesmas duas entidades desde que esses relacionamentos tenham significados diferentes. Nesse caso eles não são considerados redundantes.
Um exemplo de não-redundância: Modelo ER
UML
Se “pertence_a” é um relacionamento um-para-muitos entre Funcionário e Associaçao_Profissional, se “localizado_em” é um relacionamento um-para-muitos entre Associaçao_Profissional e Cidade, e se “mora_em” é um relacionamento um-para-muitos entre Funcionário e Cidade, então “mora_em” não é redundante porque os relacionamentos são não-relacionados. Contudo, considere a situação mostrado abaixo:
Modelo ER
O Funcionário trabalha em um Projeto localizado em uma Cidade, então o relacionamento “trabalha_em” entre Funcionário e Cidade é redundante e pode ser eliminado.
Relacionamentos ternários
Defina relacionamentos ternários cuidadosamente. Defina um relacionamento ternário entre três entidades somente quando o conceito não pode ser representador por vários relacionamentos binários entre essas entidades. Suponha que há várias associações entre as entidades Técnico, Projeto e Caderno. Se cada técnico pode trabalhar em qualquer um dos vários projetos e usando os mesmos cadernos em cada projeto, então três relacionamentos binários muitos-para-muitos podem ser definidos:
Modelo ER
UML
Se, no entanto, cada técnico é restringido a usar exatamente um caderno para cada projeto e que caderno pertence a somente um técnico, então o relacionamento ternário um-para-um-para-um deve ser definido:
Modelo ER
O significado de conectividade para relacionamentos ternário é importante. Se um relacionamento entre três entidades pode ser expresso somente por uma dependência funcional envolvendo as chaves de todas as três entidades, então não pode ser expresso usando somente relacionamentos binários, que só requer associações entre duas entidades. Projeto orientado a objeto fornece, sem dúvida, a melhor maneira para modelar essa situação.
Exercícios
1. Indique com um “X”, a correspondência entre os elementos de dados e seus atributos formadores: A. NM_MERCADORIA_PROMOCAO B. VL_MERCADORIA_FINANCIADA C. VL_TOTAL_MERCADORIA_FINANCIADA D. NM_FORNECEDOR_MERCADORIA E. CD_MERCADORIA_REPOR_ESTOQUE F. QT_MERCADORIA_REPOR_ESTOQUE G. VL_PARCELA_FINANCIAMENTO_MERCADORIA Elementos de dados A B C D E F G Atributos formadores NM_MERCADORIA VL_BASE_MERCADORIA CD_IDENTIFICACAO_MERCADORIA QT_SALDO_MERCADORIA_ESTOQUE NM_FORNECEDOR QT_PARCELA_FINANCIAMENTO IC_MERCADORIA_PROMOCAO QT_MINIMA_ESTOQUE_MERCADORIA QT_MAXIMA_ESTOQUE_MERCADORIA PC_DESCONTO_PROMOCAO_MERCADORIA
Elementos de dados
A B C D E F G Atributos formadores
PC_ACRESCIMO_TOTAL_FINANCIAMENTO_MERCADORIA
2. Indique os prováveis atributos necessários para sua formação: Elemento de dado Atributos Formadores
CD_EQUIPAMENTO_DANIFICADO NM_FUNCIONARIO NM_LABORATORIO_REMEDIO_VENCIDO CD_PARCELA_CARNE_VENCIDO NM_CLIENTE_CARNE_DEVEDOR CD_PLACA_IDENTIFICACAO_VEICULO CD_APOLICE_SEGURO_VEICULO_COLISAO DS_MERCADORIA DS_MERCADORIA_RECORDISTA_VENDA_MES CD_TIPO_MERCADORIA NM_ALUNO_MATRICULADO NM_ALUNO_TRANFERIDO VL_SALARIO_LIQUIDO VL_TOTAL_MERCADORIA_FINANCIADA
3. Descreva os diversos fluxos de dados a seguir e desenho um modelo de dados. a) Nota fiscal.
Nota Fiscal Número: Data:
Nome do Cliente:
Inscrição Estadal (se isento, não preencher): CNPJ ou CPF:
QTD Mercadoria Preço
Unitário Total
b) Tabela de preços de passagens.
Tabela de Preços de Passagens Validade: Novembro/Dezembro de 2011
Origem Destino Tipo Ônibus Preço Foz do Iguaçu Santos Comum 150,00 Foz do Iguaçu Santos Leito 170,00 Foz do Iguaçu Curitiba Comum 130,00 Foz do Iguaçu Curitiba Leito 150,00 Foz do Iguaçu Florianópolis Comum 140,00 Foz do Iguaçu Florianópolis Leito 160,00 São Paulo Santos Comum 30,00 São Paulo Santos Leito --- São Paulo Salvador Comum 300,00 São Paulo Salvador Leito 350,00 São Paulo Teresina Comum 350,00 São Paulo Teresina Leito 400,00 c) Tabela de preços de passagens.
Tabela de Preços de Passagens Validade: Novembro/Dezembro de 2011 De: Foz do Iguaçu Comum Leito
Para: Santos 150,00 170,00
Curitiba 130,00 150,00 Florianópolis 140,00 160,00
De: São Paulo Comum Leito
Para: Santos 30,00 --- Salvador 300,00 350,00 Teresina 350,00 400,00
d) Sr(a) analista, preciso de sua ajuda para controlar as ocorrências de ponto de nossos funcionários. Gostaria de receber um relatório mensal com a matrícula de cada funcionário, as datas que ele teve ocorrência de ponto, que ocorrência foi (atraso, licença, falta, etc.) e indicação se foi justificada ou não. Esta lista precisa sair separada para cada um dos nove departamentos que a empresa tem. Obrigado.
e) Histórico escolar.
Centro Universitário Tecnológico do Brasil Histórico Escolar
Nome do Aluno: João Parede Matrícula: 18.334
Curso: Processamento de Dados Início do Curso: Jan/2009
Disciplina Cód Média Situação Período Carga Hor.
Matemática MAT 6,0 Aprovado 01/09 60
Líng. Portuguesa POR 3,5 Reprovado 01/09 60 Informática Básica INF 5,0 Reprovado 01/09 90
Inglês ING 8,0 Aprovado 02/09 60
Banco de Dados BDS 6,5 Aprovado 02/09 60
Lógica LOG 9,5 Aprovado 02/09 120
f) Comunicado de transferência e promoção de funcionário.
O Sr. Maurício Mendes Macaubas, matrícula 12.276, está sendo transferido do Departamento de Contabilidade para o Departamento de Vendas a partir de 25 de setembro de 2011.
Foi promovido da função de sub-assistente de contabilidade para assessor de marketing. O novo salário será de R$ 2.300,00 (dois mil e trezentos reais) mensais. Autorizado por Fernando Mandachuva Superintendente de Contabilidade Matrícula: 5.342 g) Tabela de preço.
TAPES & SOUND’S
Av. Brasil, 512 – Conjunto 127 – Centro – Foz do Iguaçu/PR
Artista Cod.
Merc.
Tipo Merc.
Preço em reais
À vista Cheque C. Crédito Julio Iglesias 101 CD 25,00 28,00 27,00 DVD 30,00 33,00 32,00 119 DVD 35,00 40,00 37,00 Leonardo 567 CD 20,00 29,00 23,00 DVD 28,00 35,00 30,00 598 CD 22,00 22,00 22,00 DVD 30,00 33,00 33,00 Shakira 333 DVD 90,00 100,00 95,00 352 CD 22,00 23,50 22,00 DVD 32,00 35,00 32,00 4. Preencha as colunas a seguir com:
(A) Atributo (B) Elemento de dado (C) Fluxo de dado (D) Entidade (E) Processo (F) Relacionamento dt_vencimento_fatura vl_total_fatura_vencida_mes_atual confeccionar etiquetas repertório recital pertence nm_cliente_reprovado_pagamento qt_peso_equipamento faz atendimento
conferir solicitação recebida música
emitir exceções faturamento relação_cinema_cidade_foz é_representado_por nm_autor autorização_viagem_internacional resolve fatura
conciliar conta contábil conta contábil
relação veículo acidentado detém
tipo vegetal
cd_televisor_necessita_reparo vl_estimado_obra_arte
caixa eletrônico
cancelar requisição compra cardápio
qt_idade_atleta 5. Assinale V para verdadeiro e F para falso.
( ) O desenvolvimento de um sistema com ênfase top-down, facilita mais a visualização de necessidades futuras que o enfoque bottom-up.
( ) A escolha da abordagem top-down ou bottom-up na fase de projeto depende dos tipos de processadores que serão implementados os processos que tratam dos dados não corporativos.
( ) A abordagem com enfoque top-down é o tipo de abordagem mais conveniente para se elaborar o estudo de viabilidade.
( ) SolicitarVistoPassagem é um processo EmitirVistoViagem é um fluxo de dados.
( ) EmitirRecibo é um processo, CD_RECIBO_ENTREGA é um fluxo e “37.490” é um dado.
( ) Um programa pode ser parte de um fluxo de dados.
( ) QT_PRECO_VESTIDO é a forma correta de indicar o valor de venda de um vestido.
( ) Os conteúdos de NM_MERCADORIA e de DS_MERCADORIA muitas vezes são os mesmos.
( ) CD_PASSAGEM_AEREA_EMITIDA pode ser um atributo.
( ) DT_NASCIMENTO_DEPENDENTE é um dado do tipo natural, portanto não pode ser um elemento de dado.
( ) A grande preocupação de um usuário é com os elementos de dados e não com os atributos.
( ) Um elemento de dado jamais poderá ter o mesmo nome de um atributo. ( ) A função de um fluxo de dados é manipular e transformar os dados.
( ) Só pode ser eficaz um sistema de informações desenvolvido com metodologia de enfoque top-down.
( ) Uma metodologia com enfoque top-down não trata de dados não corporativos.
( ) Um caderno pode fazer parte de uma base de dados de um sistema de informações.
( ) O modelo conceitual de dados é definido na fase de análise, já a definição do modelo lógico se faz na fase de projeto.
( ) Durante a construção do modelo conceitual de dados não há participação de usuários.
( ) EmitirRequisicaoCompra é o nome de um processo, Requisicao_Compra é um fluxo de dados e CD_REQUISICAO_COMPRA é um elemento de dado ou um atributo.
( ) O modelo de dados deve ser inicialmente construído levando-se em conta os processos envolvidos no sistema.
( ) Entidade é um conjunto de coisas concretas e abstratas do mundo real a qual há interesse em guardar informações.
( ) NM_CLIENTE é uma tupla da entidade CLIENTE.
( ) Conceitualmente não há diferença entre NM_ALUNO e Juliana Paes. ( ) O elemento de dado faz parte do fluxo de dados, enquanto o atributo forma
a entidade.
( ) Um atributo pode ter vários conteúdos iguais, mas o modelo de dados não pode ter dois atributos iguais.
( ) Quando se diz que há um relacionamento entra duas entidades, na realidade o que ocorre é o relacionamento entre as tuplas das entidades.
( ) O usuário do tipo operativo é o mais indicado para entender o modelo conceitual de dados.
( ) Solicitacao_Emprego é um nome de fluxo.
( ) NUM_MATRICULA_FUNCIONARIO indica o número da matrícula de um funcionário.
( ) Para se construir o modelo físico de dados não é necessário antes construir o modelo conceitual de dados.
Bibliografia
Database Modeling and Design: Logical Design
Toby Teorey, Sam Lightstone, Tom Nadeau, H. V. Jagadish USA: Elsevier, 2011
Beginning Database Design Gavin Powell
USA : Wiley Publishing, Inc., 2006
Database Design for Mere Mortals – 2ª edição Michal J. Hernandez
