Análise de Requisitos e Modelo
Conceitual de Dados
O projeto lógico de banco de dados é realizado com uma variedade de abordagens, incluindo as metodologias top-down e bottom-up combinadas. A abordagem tradicional, particularmente para banco de dados relacionais, tem sido um baixo-nível, atividade bottom-up, sintetizando elementos de dados individuais em tabelas normalizadas após análise das interdependências dos elementos de dados definidos pela análise de requisitos. Embora o processado tradicional tem sido um pouco bem sucedido para banco de dados de pequeno e médio tamanho, quando usado para grandes bancos de dados sua complexidade pode ser esmagadora para o ponto onde a prática da análises não se preocupa em usá-lo com alguma regularidade. Na prática, a combinação das abordagens top-down e bottom-up é utilizada; na maioria dos casos, tabelas podem ser definidas diretamente através das análises de requisitos.
O modelo conceitual de dados tem sido mais bem sucedido como uma ferramenta para 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 a abordagem top-down utiliza 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 normalmente representam os atributos. Portanto, usar entidades como uma abstração para elementos de dados e focar nos relacionamentos entre entidades reduz significativamente o número de objetos sob consideração e simplifica a análise. Embora ainda é necessário representar elementos de dados por atributos de entidades no nível conceitual, suas dependências são normalmente restringidas para os outros atributos dentro da entidade ou, em alguns casos, para aqueles atributos associados com outras entidades com um relacionamento direto para suas entidades.
A maior interdependência de atributos que ocorre 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 seguiu.
A abordagem do projeto lógico de banco de dados definido aqui utiliza ambos, o modelo conceitual de dados e o modelo relacional em fases sucessivas. Se beneficia da simplicidade e facilidade do uso do modelo conceitual de dados e a estrutura e formalismo associado do modelo relacional. A fiim de facilitar essa abordagem, é necessário construir uma quadro para transformar a variedade construções do modelo conceitual de dados dentro das tabelas que já estão normalizadas ou podem ser normalizadas com um mínimo de transformação. A beleza desse tipo de transformação é que resulta em tabelas SQL normalizadas ou quase normalizadas desde o início; frequentemente, mais normalização não é necessário.
Antes de nós fazermos isso, contudo, nós precisamos primeiro definir as etapas principais da metodologia do projeto lógico relacional no contexto do ciclo de vida do banco de dados.
Análise de requisitos
Análise de requisitos é um passo extremamente importante no ciclo de vida do banco de dados e é tipicamente o mais trabalhoso. O analista de banco de dados deve entrevistar a população de usuários finais e determinar exatamente o que o banco de dados é para ser usado e o que deve conter. Os objetivos básicos da análise de requisitos são:
Para delinear os requisitos de dados da empresa em termos de elementos de dados básicos.
Para descrever a informação sobre os elementos de dados e os relacionamentos entre eles necessários para modelar esses requisitos de dados.
Para determinar os tipos de transações que são desejadas para serem executadas no banco de dados e a interação entre as transações e os elementos de dados.
Para definir qualquer desempenho, integridade, segurança, ou restrições administrativas que devem ser impostas no banco de dados resultante.
Para especificar qualquer projeto e restrições de implementação, tal como tecnologias específicas, hardware e software, linguagens de programação, políticas, padrões ou interfaces externas.
para bem documentar todas as anteriores em uma especificação de requisitos detalhados. Os elementos de dados também podem ser definidos em um sistema de dicionário de dados, muitas vezes fornecidas como uma parte integral do sistema de gerenciamento de banco de dados.
O modelo conceitual de dados ajuda o analista capturar precisamente os requisitos de dados reais porque exige-os para focar em detalhes de semântica nos relacionamentos de dados, que é maior que o detalhe que seria fornecido por uma dependência funcional exclusiva.
Modelo conceitual de dados
Os elementos de dados e relacionamentos podem ser definidos durante a análise de requisitos e o projeto conceitual. Esses dois passos do ciclo de vida são frequentemente feitos simultaneamente.
Considere os subpassos no modelo conceitual de dados usando o modelo ER: Classificar 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
Embora seja fácil definir construção de entidade, atributo e relacionamento, não é tão fácil distinguir suas regras na modelagem do banco de dados. O que faz um elemento de dado uma entidade, um atributo, ou mesmo um relacionamento? Por exemplo, sedes dos projetos são localizadas em cidades. Poderia “cidade” ser uma entidade ou um atributo? Uma faixa é mantida para cada funcionário. “Faixa” é uma entidade ou um relacionamento?
As seguintes diretrizes para classificar entidades e atributos ajudarão nos pensamentos do analista converge para um projeto de banco de dados relacional normalizado:
Entidades devem conter informação descritiva.
Atributos multivalorados devem ser classificados como entidades.
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. A exceção para essa regra é que se a identidade do valor precisa ser restringido para um conjunto de membros, você deve criá-la como uma entidade. Por exemplo, “estado” é quase da mesma forma como cidade, mas provavelmente você quer ter uma entidade Estado que contém todas as instâncias válidas de Estado. 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 companhia pode ter muitas divisões, algumas delas possivelmente em diferentes cidades. Nesse caso, divisão ou nm_divisao deve ser classificado como um atributo multivalorado da entidade Companhia (e sua chave, id_companhia). O atributo nm_endereco_sede de uma companhia, por outro lado, normalmente seria um atributo de valor único.
Classificar atributos multivalorados como entidades. 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. Se atributos são restritos para serem somente valores simples, o projeto final e as decisões de implementações serão simplificadas.
Ligação de atributo
Ligar 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. O procedimento de identificação de entidades e ligação de atributos a entidades é iterativo. Classificar algums elementos de dados como entidades e associar identificadores e descritores a eles. Se você encontrar alguma violação das diretrizes anteriores, troca alguns elementos de dados de entidade para atributo (ou de atributo para entidade), associa atributos para novas entidades, e assim por diante.
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,
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.
Nós determinamos, através da nossa análise, que 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
Nós agora lidaremos com elementos de dados que representam associações entre entidades, que nós chamamos relacionamentos. Exemplos de relacionamentos típicos são trabalha_em, trabalha_para, compra, dirige, ou algum verbo que conecte entidades. Para todo o relacionamento o seguinte deve ser especificado: grau (binário, ternário, etc.), conectividade (um-para-muitos, etc.), existência opcional ou obrigatória, e alguns atributos que são associados com o relacionamento e não com as entidades. Abaixo algumas diretrizes para definir os mais difíceis tipos de relacionamentos.
Relacionamentos redundantes
Análise relacionamentos redundantes cuidadosamente. Dois ou mais relacionamentos que são 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 dentro de esquemas relacionais. Veja que dois ou mais relacionamentos são permitidos entre as mesmas duas entidades enquanto que esses relacionamentos tenham significados diferentes. Nesse caso eles não são considerados redundantes.
Um importante caso de não-redundância é mostrado na figura abaixo: Modelo ER
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
UML
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. Nós definimos um relacionamento ternário entre três entidade somente quando o conceito não pode ser representador por vários relacionamentos binários entre essas entidades. Por exemplo, vamos assumir que há várias associações entre as entidades Técnico, Projeto e Caderno. Se cada técnico pode estar trabalhanco em vários projetos e usando os mesmos cadernos em cada projeto, então três relacionamentos binários muitos-para-muitos podem ser definidos:
UML
Se, contudo, 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
UML
A abordagem para adotar a modelagem ER é a primeira tentativa de expressar as associações em termos de relacionamentos binários; se isto é impossível por causa das restrições de associações, tente expressá-los em termos de um relacionamento ternário.
O significado de conectividade para relacionamentos ternário é importante. A figura acima mostra que para um dado par de instâncias de Técnico e Projeto, há somente uma instância correspondente de Caderno; para um dado par de instâncias de Técnico e Caderno, há somente uma instância correspondente de Projeto; e para um dado par de instâncias Projeto e Caderno, há somente uma instância de Técnico. Em
geral, nós sabemos pela definição de relacionamentos ternários que se um relacionamento entre três entidades podem ser expressado somente por uma dependência funcional envolvendo as chaves de todas as três entidades, então não pode ser expressando 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 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_tranferencia
2. 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 Educacional 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 3. 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
