Baixe o app para aproveitar ainda mais
Prévia do material em texto
Apostila – Unidade 3 Modelo Físico Módulo 1 Disciplina: Banco de Dados Relacional e NoSQL Profª Bruna Bárbara Santos Bordini 1 Modelo Físico De acordo com Machado (2014), o modelo fisico de um banco de dados é construido a partir do modelo lóico e descreve as estruturas fisicas de armazenamento de dados, tais como: Tipo e tamanho de campos; Índices; Dominio de preenchimento desses campos; Nomenclaturas; Exíencia de conteudo; Gatilhos etc. Estas estruturas sao projetadas de acordo com os requisitos de processamento e uso mais economico dos recursos computacionais. O modelo fisico detalha o estudo dos métodos de acesso do SGBD para cria̧ao dos indices necesśrios para cada informa̧ao colocada nos modelos conceitual e lóico. Esta é a etapa final do projeto de banco de dados, na qual seŕ utilizada a lińuáem de defini̧ao de dados do SGBD (DDL) para a realiza̧ao da sua montáem no diciońrio de dados. Em ambiente de banco de dados relacional denominamos script de cria̧ao do banco de dados o conjunto de comandos em SQL (DDL) que seŕ executado no Sistema Gerenciador de Banco de Dados para a cria̧ao de banco de dados correspondente ao modelo fisico. 1.1 O modelo físico em si Nesta etapa, o analista passa as visoes do modelo conceitual para o modelo lóico relacional, no qual os dados sao vistos como estruturas de dados voltadas para as caracteristicas da abordáem escolhida, objetivando a implementa̧ao do banco de dados. O modelo fisico prove um contexto para defini̧ao e réistro no cat́lóo do banco de dados dos elementos de dados que formam um database, por assim dizer, e fornece aos analistas de uma aplica̧ao a possibilidade de escolha dos caminhos e acesso as estruturas de dados (MACHADO, 2014). Na cria̧ao de um modelo fisico de dados, realizada pela conversao do modelo conceitual, possuimos uma lista de conceitos dos componentes de cada modelo e sua equivalencia, que pode orientar na rela̧ao dos termos utilizados que vamos apresentar neste capitulo, além de considera̧oes ́erais sobre o processo. A transforma̧ao de um modelo conceitual ou lóico em modelo fisico exíe que sejam realizadas as defini̧oes dos atributos de uma tabela (colunas) que serao indices, como seŕ o tipo desse atributo (numérico, caractere, data, outros), assim como a exíencia de sua existencia ou nao, sua identifica̧ao como chave priḿria ou estrańeira na tabela em si. Na realidade, vamos adequar o tipo de dado ao tipo de dado permitido, implementado pelo Sistema Gerenciador de Banco de Dados Relacional com que vamos trabalhar. As principais ferramentas CASE do mercado possuem interfaces de conversao do modelo lóico no modelo fisico, que disponibilizam o tipo de dado correto e permitido para cada SGBD usualmente utilizado, além de permitirem assinalamento das outras caracteristicas de um modelo fisico necesśrio. A Fíura 1 apresenta um modelo de representa̧ao fisica de um modelo de dados. Fíura 1- Representa̧ao fisica de um modelo de dados (Fonte: Machado, 2014). 1.1.1 Propriedades de uma coluna Quando um modelo lóico é convertido em um modelo fisico, cada um dos atributos existentes nas entidades do modelo deve possuir áora um conjunto de propriedades relativas a uma coluna de uma tabela. As propriedades que devem ser séuidas neste processo de conversao de modelo lóico em modelo fisico dizem respeito, em sua ́rande parte, a informa̧oes de implementa̧ao sobre cada coluna da tabela a ser criada. Réras para a cria̧ao do modelo fisico de dados (MACHADO, 2014): O nome da coluna seŕ restrińido pelas conveņoes e réras de metodolóia utilizada ou da administra̧ao de dados da empresa, bem como pelos requisitos semânticos do SGBD. O tipo de dado seŕ limitado aqueles suportados pelo SGBD. Vale ressaltar que cada SGBD possui caracteristicas proprias que determinam os tipos de dados aceitos por ele. Toda coluna deve ter preestabelecido o tipo de dado que pode conter. Por exemplo, se um campo de uma tabela for do tipo numérico, ele nao pode receber dados que forem letras. Tipos de Dados Mais Comuns (Padrao ANSS): Em séuida temos de definir se a existencia de valor de dados é obríatoria para a coluna ou nao. 1.1.2 A opço de nulo Por padrao, as chaves priḿrias sao definidas como not null, ou seja, nao admitem a inexistencia de valor em qualquer uma das colunas que a compoem. 1.1.3 Uma regra de validaço Se existir a réra de valida̧ao, ela deve conter uma lista de valores v́lidos para a coluna que voce define. As réras de valida̧ao podem ser intervalos de valores ou um codío em SQL (MACHADO, 2014). Uma réra de valida̧ao é uma expressao que estabelece o intervalo de valores aceit́veis que podem ser armazenados em uma coluna. A utiliza̧ao e a implementa̧ao no modelo fisico de tabelas de dominio para colunas de uma tabela sao uma alternativa as réras de valida̧ao em aĺuns casos. Se a lista de valores v́lidos for voĺtil ou lońa, pode ser preferivel usar, em sua substitui̧ao, uma tabela de dominio, visto que uma tabela de dominio seŕ mais f́cil de ser atualizada no ambiente de produ̧ao. As tabelas de dominio podem e devem ser criadas somente no modelo fisico, pois sao objetos apenas fisicos, uma vez que elas nao tem base nem existem no modelo conceitual ou no modelo lóico. Se a lista de valores for est́vel, o uso da réra de valida̧ao pode ser a melhor op̧ao. Ssso sínifica uma tabela a menos no banco de dados para cada réra usada. A Fíura 2 apresenta um exemplo de réra de néocios. Fíura 2 – Exemplo de réra de néocios (Machado, 2014). Réra de néocios: o numero de itens por nota fiscal est́ sempre entre 5 e 15 . Outro exemplo de réra de valida̧ao, réra de valida̧ao StatusNotaFiscal: F = 'Faturada' C = 'Cancelado' Por exemplo, se a empresa nao permitisse cancelar uma nota com data de tres dias antes do dia da propria nota, neste caso, teriamos a réra de valida̧ao: 1.1.4 Valor padŗo É o valor colocado na coluna durante uma inseŗao de réistro na tabela na ausencia de qualquer outro valor para aquela coluna. Conhecido como valor default do atributo. 1.1.5 Visões de Dados Uma visao do banco de dados (database view) é uma apresenta̧ao personalizada dos dados armazenados em uma ou mais tabelas. As visoes também sao conhecidas como tabelas virtuais ou consultas armazenadas (MACHADO, 2014). Uma visao pode: Sncluir um subconjunto de colunas de uma tabela do banco. Sncluir colunas de multiplas tabelas do banco. Ser baseada em outras visoes em vez das tabelas do banco. NumStensNota >= 5 and NumStensNota <= 15 NOT StatusNotaFiscal="C"(date < (DataNota+3) AND StatusNotaFiscal = "F") Ser consultada, atualizada, inserida e apáada. Todas estas a̧oes afetam os dados armazenados nas tabelas do banco, com aĺumas restri̧oes. Pode ser frequentemente alterada para se adequar as necessidades de altera̧ao sem exíir uma mudaņa para a tabela do banco subjacente. É importante lembrar que as visoes exibem dados das tabelas do banco, mas nao armazenam dados. Podemos ter no modelo fisico de dados a inseŗao de visoes de dados no sentido de criar limita̧oes ou restri̧oes ao acesso amplo da aplica̧ao a todos os dados de uma tabela, ou na ańlise de volumes de dados criar visoes de subtipos para acesso distinto de usúrios. As visoes podem ser usadas para fornecer um nivel adicional de séuraņa de tabelas, ocultar a complexidade de determinados dados, simplificar os comandos para usúrios, fornecer diferentes apresenta̧oes de dados ou armazenar consultas complexas, evitando que se consumam recursos de processamento elevados desnecessariamente. A Fíura 3 apresenta um exemplo de visao. As visoes de dados somente existem no modelo fisico, e as suas colunas podem ser:colunas de tabela, colunas de outras visoes ou expressoes em SQL. Fíura 3 – Exemplo de visao (Fonte: Machado, 2014). 1.2 Indexaço Um indice é uma estrutura associada a uma tabela que torna a pesquisa mais ŕpida. A indexa̧ao é utilizada visando a otimiza̧ao do banco de dados. Com o uso do indice, a localiza̧ao de um réistro torna-se mais ŕpida durante uma consulta. Entretanto, pode haver uma diminui̧ao de rendimento com a utiliza̧ao de indices. À medida que mais indices sao criados, o banco de dados realiza mais lentamente atualiza̧oes. Por exemplo, cada vez que uma inseŗao é realizada em uma coluna indexada, cada indice precisa ser atualizado. Tecnicamente nao h́ limite ao numero de indices, mas quanto maior o numero deles mais dificil fica a sua manuteņao. Outro aspecto a considerar para inseŗao de indices em uma tabela é a sua utiliza̧ao nas consultas mais frequentes, pois conforme a disposi̧ao e execu̧ao dessa consulta, principalmente se estivermos utilizando multiplas juņoes, esses indices nao serao totalmente utilizados quando da sua execu̧ao. A escolha de indexa̧ao de colunas depende também do néocio para o qual o BD foi modelado, sendo preciso considerar: As atualiza̧oes ou consultas sao muito criticas? Qual é o volume de dados previsto para a tabela? Quao voĺtil seŕ essa tabela? Para tabelas de um Data Warehouse, por exemplo, quase tudo é indexado porque os requisitos do néocio sao consultas ŕpidas e as tabelas possuem baixa volatilidade. 1.2.1 Chaves Substitutas Para Machado (2014), é comum que a chave priḿria de uma tabela seja substituta, ou seja, é criada uma coluna que contém um numero ou codío de identifica̧ao que é um identificador unico, mas que nao tem um sínificado intrinseco no que se refere ao objeto sendo modelado. Uma chave substituta é artificial e seŕ usada como uma substituta para uma chave natural, derivada dos relacionamentos da tabela. A inseŗao de chaves substitutas no modelo fisico é uma realidade, mas deve ser feita de forma criteriosa, pois implica na existencia de processos de consistencia das colunas que oríinalmente compunham a chave priḿria da tabela, e que foram definidas no modelo lóico. Efetivado o modelo fisico de dados, estamos aptos a criar o banco de dados projetado pela ́era̧ao de um script de comandos SQL para o SGBD. 1.3 Dicionário de dados O diciońrio de dados é um documento com a descri̧ao de cada elemento do banco de dados: Tabelas. Atributos. Chaves priḿrias. Chaves estrańeiras. Relacionamentos. Cardinalidade. Esta documenta̧ao permite que qualquer profissional que venha a trabalhar com o banco seja capaz de entender seus elementos. A Fíura 4 apresenta um modelo de diciońrio de dados e a Fíura 5 apresenta um exemplo. Tabela: <Nome da Tabela> Nome Descri̧ao Tipo Tamanho Dominio Formato Restri̧oes <campo 1> <descrição do campo 1> <tipo 1> <tamanho 1> <domínio 1> <formato 1> <regra 1> <campo 2> <descrição do campo 2> <tipo 2> <tamanho 2> <domínio 2> <formato 2> <regra 2> <campo 3> <descrição do campo 3> <tipo 3> <tamanho 3> <domínio 3> <formato 3> <regra 3> … <campo n> <descrição do campo n> <tipo n> <tamanho n> <domínio n> <formato n> <regra n> Fíura 4 – Modelo de um diciońrio de dados. Tabela: Clientes Nome Descri̧ao Tipo Tamanho Dominio Formato Restri̧oes Codío Codío que identifica unicamente os dados de um Cliente no Banco de Dados. Snteiro - - - - Nome Nome Completo do Cliente. Texto 60 - - - CPF Numero do Cadastro de Pessoa Fisica do Cliente. Texto 11 - 999999999-99 O CPF deve ser v́lido Sexo Sexo do Cliente (Masculino ou Feminino), Texto 1 M – Masculino F – Feminino - Data de Nascimento Data de Nascimento do Cliente. Data 10 - DD/MM/AAAA O Cliente deve ser maior de idade. Fíura 5 – Exemplo de diciońrio de dados. 2 Referências MACHADO, Felipe Rodríues. Banco de Dados - Projeto e Smplementa̧ao, 3ª edi̧ao. Érica, 2014.
Compartilhar