MODELO LÓGICO DE DADOS (MLD)

MODELO LÓGICO DE DADOS (MLD) Olá, Turma! Neste capítulo, daremos prosseguimento ao nosso trabalho de modelar o negócio para o qual estaremos desenvolvendo um sistema. Quando vamos trabalhar com o modelo lógico, já deveremos ter o modelo conceitual finalizado. Estaremos, então, aplicando certas restrições técnicas ao modelo conceitual para que seja possível implementar este modelo em um tipo de SGBD escolhido. No final, veremos o modelo físico e, nessa parte, iremos inserir características de um específico SGBD. Os objetivos deste capítulo são: saber colocar o modelo na terceira forma normal; Muitos autores e profissionais da área, em suas abordagens sobre o tema modelagem de dados, têm direcionado o processo de modelagem diretamente para o nível lógico. Partem, desde o início de seu processo, para a construção de um modelo fortemente dependente do ambiente onde será implementado. Isso tem levado à obtenção de modelos eficientes, mas bastante dependentes da tecnologia que os orientou (relacional, redes, orientado a objetos). Dentro da proposta apresentada nos itens anteriores, vimos que a geração de um modelo lógico deveria ser antecedida pela obtenção de um modelo conceitual. Esse modelo conceitual deveria ser independente da tecnologia disponível, procurando aproximar-se o máximo possível do mapeamento fiel do ambiente observado. No modelo conceitual, você pode e deve representar o negócio sem limitações técnicas. Existem várias notações para o modelo lógico. Em nossa disciplina, vamos utilizar a notação de James Martin (Engenharia de Informações) que foi criada em 1980 e é uma das mais utilizadas no mercado de trabalho.

38 EROS MOURA Empregado (0,n) (1,1) Trabalha Departamento EMPREGADO DEPARTAMENTO = muitos = um = a ocorrência do relacionamento é opcional = a ocorrência do relacionamento é obrigatória Os relacionamentos já não são mais nomeados. Só será necessário nomear um relacionamento quando houver mais de um relacionamento entre duas tabelas. Lógicos ou de implementação (nível intermediário) entre o Modelo Conceitual e o Modelo Físico. A grande vantagem dessa proposta é que, a partir do modelo conceitual gerado, poderemos aplicar regras predefinidas em função da tecnologia a ser empregada e, assim, obter os modelos necessários. Isso fará com que, a partir de um mesmo modelo conceitual, possamos gerar modelos lógicos para bancos de dados baseados na abordagem relacional ou até mesmo em novas abordagens, tais como bancos de dados orientados a objetos. Assim, podemos definir que o processo de obtenção de um modelo lógico a partir de um modelo conceitual segue os seguintes passos, segundo Cougo (1997): 4. adaptar o modelo às necessidades.

BANCO DE DADOS 39 Perceba que, dentre os passos a serem seguidos, existe, em último lugar, uma atividade extremamente importante para a geração de um modelo lógico aplicável efetivamente à solução de problemas práticos do dia a dia. Estaremos utilizando o programa DBDesigner para criar nossos modelos lógicos. Há uma versão dele que pode ser encontrada aqui: http://sourceforge.net/projects/dbdesigner-fork/files/dbdesignerfork/r1.5/dbdesignerfork-1.5-bin-i386-win32-beta5.zip/ download 2.1. REGRAS DE DERIVAÇÃO Como citamos anteriormente, a obtenção de um modelo lógico deveria ser feita a partir de um modelo conceituai previamente gerado. Para tanto, deveríamos dispor de uma série de regras de derivação que fossem aplicadas sobre o modelo conceitual e que o transformassem em função da topologia (tipo) de BD usada, em um modelo relacional, rede ou até hierárquico. Veremos, a partir deste instante, portanto, essas regras. Como nosso objetivo, neste material, é explorar a derivação de modelos relacionais, estaremos trabalhando com as regras para o modelo relacional segundo Elmasri e Navathe (2011). 2.1.1. Etapa 1: Mapeamento de tipos de entidade regular Para cada tipo de entidade regular (forte) E no modelo conceitual, crie uma tabela T que inclua todos os atributos simples de E. Inclua apenas os atributos de componente simples de um atributo composto. Escolha um dos atributos-chave de E como chave primária para T. Se a chave escolhida de E for composta, então o conjunto de atributos simples que a compõem juntos formarão a chave primária de T. Se várias chaves fossem identificadas para E durante o projeto conceitual, a informação que descreve os atributos que formam cada chave adicional é mantida a fim de especificar chaves secundárias (únicas) da tabela T. O conhecimento sobre as chaves também é mantido para fins de indexação e outros tipos de análises. Em nosso exemplo, criamos as tabelas JOGO, EQUIPE, JOGADOR e PAÍS. Os atributos de chave estrangeira e relacionamento se houver,

40 EROS MOURA seguintes. Em nosso exemplo, escolhemos data_jogo e nome_estadio chave primária de PAÍS. 2.1.2. Etapa 2: Mapeamento de tipos de entidade fraca Para cada tipo de entidade fraca F no modelo conceitual: com tipo de entidade proprietária forte E, crie uma tabela T e inclua todos os atributos simples (ou componentes simples dos atributos compostos) de F como atributos de T. Além disso, inclua como atributos chave estrangeira de T os atributos de chave primária da tabela que correspondem aos de entidade proprietária E. Isso consegue mapear o tipo de relacionamento de identificação de F. A chave primária de T é a combinação das chaves primárias do proprietário E e a chave parcial do tipo de entidade fraca F, se houver. Se houver um tipo de entidade fraca E2, cujo proprietário também é um tipo de entidade, então Ej deve ser mapeado antes de E2 para determinar primeiro sua chave primária. Em outras palavras, se houver uma entidade fraca (E2), ligada a outra entidade fraca (E1), E1 deve ser criada antes de E2. 2.1.3. Etapa 3: Mapeamento dos tipos de relacionamento binários 1:1 Para cada tipo de relacionamento binário 1:1 R no modelo conceitual, identifique as tabelas A e B que correspondem aos tipos de entidades participantes em R. Escolha entre as tabelas A e B e inclua a chave estrangeira referenciando a outra. Por exemplo: coloco a chave estrangeira em A referenciando B. Complementando: já criamos duas tabelas ( A e B ), uma para cada conjunto de delas, incluir como chave estrangeira a chave primária da se o relacionamento for total em um dos dois conjuntos de entidades, então é melhor incluir a chave estrangeira no lado total.

BANCO DE DADOS 41 2.1.4. Etapa 4: Mapeamento de tipos de relacionam binário 1:N Para cada tipo de relacionamento R binário regular 1:N, identifique a tabela T que representa o tipo de entidade participante no lado N do tipo de relacionamento. Inclua como chave estrangeira em T a chave primária da tabela P que representa o outro tipo de entidade no lado N (tabela T ) está relacionada, no máximo, a uma instância de entidade do lado 1 (tabela P ) do tipo de relacionamento. Inclua quaisquer atributos simples (ou componentes simples dos atributos compostos) do tipo de relacionamento 1:N como atributos de P. Complementando: já temos duas tabelas ( T, P ), uma para cada conjunto de incluir como chave estrangeira, na tabela do lado muitos (o lado N ), a chave primária da tabela do lado um. 2.1.5. Etapa 5: Mapeamento de tipos de relacionamento binário N:N Para cada tipo de relacionamento R binário N:N, crie uma nova tabela S para representar R. Inclua como atributos de chave estrangeira em S as chaves primárias das tabelas que representam os tipos de entidade também, quaisquer atributos simples do tipo de relacionamento N:N (ou componentes simples dos atributos compostos) como atributos de S. Observe que não podemos representar um tipo de relacionamento N:N por um único atributo de chave estrangeira em uma das tabelas participantes (como fizemos para os tipos de relacionamento 1:1 ou 1:N) devido à razão de cardinalidade, por isso temos de criar uma tabela de relacionamento S separada. Complementando: já temos duas tabelas, uma para cada conjunto de entidades criar uma nova tabela contendo, como chaves estrangeiras, as a combinação dessas chaves estrangeiras forma a chave incluir também, se houver, colunas com os atributos do relacionamento.

42 EROS MOURA 2.1.6. Etapa 6: Mapeamento de atributos multivalorados Para cada atributo multivalorado A na tabela S, crie uma tabela T. Essa tabela T incluirá um atributo correspondente a A, mais o atributo da chave primária da tabela S. A chave primária de T é a combinação do atributo da chave primária da tabela S (esse atributo também será chave estrangeira) e o atributo A. Se o atributo multivalorado for composto, incluímos seus componentes simples. Complementando: Para cada atributo multivalorado, criar uma tabela contendo: como chave estrangeira, a chave primária da tabela que possuía a nova chave primária também será uma chave estrangeira a chave primária da nova tabela é a combinação da chave se o atributo multivalorado for composto, incluímos seus componentes simples. 2.1.7. ETAPA 7: MAPEAMENTO DE AUTORRELACIONAMENTO 1:N Para os autorrelacionamentos 1:N, como existe um relacionamento entre a mesma entidade, deve-se criar a chave estrangeira na própria tabela, no atributo que tem o relacionamento. Nesse caso, o atributo que terá a chave estrangeira não terá o mesmo nome da chave primária, pois não é possível repetir o nome do atributo. FUNCIONÁRIO (1,n) (1,1) matrícula nome_funcionário matrícula_gerente é gerenciado por é gerente de GERÊNCIA

BANCO DE DADOS 43 Ao final, teremos a tabela assim: FUNCIONARIO (matricula, nome_funcionario, matricula_gerente) sendo que o atributo matricula_gerente terá uma chave estrangeira para FUNCIONÁRIO. 2.1.8. Etapa 8: Autorrelacionamento N:N Para os autorrelacionamentos N:N, faremos da mesma forma que um relacionamento N:N tradicional, ou seja, criamos uma nova tabela para o relacionamento. Esta nova tabela terá, ao menos, duas colunas as quais serão, ao mesmo tempo, chave primária e chaves estrangeiras. Neste caso, as duas chaves estrangeiras estarão se referenciando à mesma tabela base. DISCIPLINA (0,n) (0,n) cod_disciplina nome_disciplina carga_horária são pré-requisito para DISCIPLINA (cod_disciplina, nome_disciplina, carga_horaria) PRE_REQUISITO (cod_disciplina, cod_disciplina_pre) cod_disciplina terá uma chave estrangeira apontando para DISCIPLINA. cod_disciplina_pre terá uma chave estrangeira apontando para DISCIPLINA. 2.1.9. Etapa 9: Mapeamento de tipos de relacionamento n-ário (qualquer relacionamento maior que o binário). Para cada tipo de relacionamento n-ário R, onde n > 2, crie uma tabela T para representar R. Inclua como atributos de chave estrangeira em T as chaves primárias das tabelas que representam as entidade participantes.

44 EROS MOURA Inclua, também, quaisquer atributos simples do tipo de relacionamento n-ário (ou componentes simples de atributos compostos) como atributos de T. A chave primária de T normalmente é uma combinação de todas as chaves estrangeiras que referenciam as tabelas representando as entidades participantes. Porém, se as restrições de cardinalidade sobre qualquer um dos tipos de entidade E participantes em R for 1, então a chave primária de T não deve incluir o atributo de chave estrangeira que referencia a relação E correspondente a E. Complementando: criar uma nova tabela contendo, como chaves estrangeiras, as chaves primárias das tabelas que representam os conjuntos de entidades normalmente, a combinação dessas chaves estrangeiras forma a chave primária da nova tabela, mas se a cardinalidade máxima de uma das entidades participantes for 1, então a chave estrangeira que referencia essa entidade não fará parte da chave primária da nova tabela. A tabela abaixo resume as correspondências entre as construções e restrições do modelo conceitual para o modelo lógico. MODELO CONCEITUAL Tipo de entidade Tipo de relacionamento 1:1 ou 1:N Tipo de relacionamento N:N Tipo de relacionamento n-ário Atributo simples Atributo composto Atributo multivalorado Conjunto de valores Atributo-chave MODELO LÓGICO Tabela Chave estrangeira (ou tabela) Nova tabelae duaschaves estrangeiras Nova tabela Atributo Conjunto de atributos componentes simples Tabela e chave estrangeira Domínio Chave primária

BANCO DE DADOS 45 2.1.10. Etapa 10: Mapeamento da especialização / generalização Tomemos como base este modelo conceitual. CLIENTE código nome PESSOA FÍSICA CPF PESSOA JURÍDICA CNPJ Para os casos em que há generalização / especialização, há três opções de projeto que podem ser adotadas: Opção 1: criar uma tabela para cada entidade (CLIENTE, FÍSICA, JURÍDICA). Nesse caso, a chave primária das tabelas especializadas (FÍSICA e JURÍDICA) é a mesma da entidade generalista (CLIENTE) e também devem ser chaves estrangeiras para a tabela CLIENTE. Ao final, teremos três tabelas, assim: CLIENTE (cod_cliente, nome_cliente) FISICA (cod_cliente, cpf, sexo) JURIDICA(cod_cliente, cnpj, nome_fantasia) OBS: aqui, a chave primária está sublinhada. Lembre-se de que: A coluna cod_cliente na tabela FISICA deverá ter chave estrangeira para CLIENTE. A coluna cod_cliente na tabela JURIDICA deverá ter chave estrangeira para CLIENTE. Opção 2: criar uma tabela para cada entidade da especialização, como FÍSICA e JURIDICA. Nesse caso, os atributos da entidade genérica (em nosso exemplo CLIENTE) devem ser incluídos em ambas as tabelas criadas.

46 EROS MOURA Ao final, teremos duas tabelas, assim: FISICA (cod_cliente, nome_cliente, cpf, sexo) JURIDICA (cod_cliente, nome_cliente, CNPJ,nome_fantasia) Opção 3: criar uma única tabela, incluindo os atributos das 3 entidades. Nesse caso, os campos que eram das entidades especializadas deverão ser opcionais, ou seja, deverão aceitar valores nulos. Ao final, teremos a única tabela, assim: CLIENTE (cod_cliente, nome_cliente, cpf, sexo, cnpj, nome_fantasia) Qual opção escolher? Cada uma das opções apresentadas traz vantagens e desvantagens. A terceira opção tem como vantagem a redução do número de junções (veremos isso mais adiante) entre tabelas e como desvantagem possuir atributos que só terão valores preenchidos quando for o caso dos dados especializados. Por exemplo: quando for o caso de cadastrar uma pessoa física, os campos CNPJ e nome fantasia não serão preenchidos. O mesmo atributos CPF e sexo não serão preenchidos. É por esse motivo que os atributos que vieram das entidades especializadas devem aceitar nulo, pois assim passam a ser opcionais. Para a segunda opção, temos como desvantagem a repetição dos atributos que eram da entidade generalista. Agora, estes atributos deverão existir nas duas tabelas. Na primeira opção há uma organização maior, pois são preservadas as estruturas que existiam no modelo conceitual. O problema dessa solução é a quantidade de junções que aumentará em relação às outras duas soluções, o que pode ser traduzido em problemas de performance. Deve-se, então, verificar se esta tabela terá muito acesso, e se o acesso a este dado, um pouco mais lento, poderá trazer problemas para a aplicação. 2.2. NORMALIZAÇÃO Finalizado o esquema relacional, passa-se ao processo de normalização. Este processo baseia-se no conceito de forma normal. Uma forma normal é uma regra que deve ser obedecida por uma tabela para que esta seja considerada bem projetada. Há diversas formas normais, isto é, diversas regras, cada vez mais rígidas, para verificar tabelas relacionais. Em nossa disciplina, vamos considerar três formas normais. As formas normais são denominadas simplesmente primeira, segunda e terceira forma normal, abreviadamente 1FN, 2FN e 3FN.

BANCO DE DADOS 47 Embora a normalização seja um ingrediente muito importante do projeto de bancos de dados, não se deve assumir que seu nível mais alto seja sempre o mais desejável. Em geral, quanto mais alta a forma normal, mais operações de junção são necessárias para produzir a saída especificada e mais recursos são exigidos pelo sistema de banco de dados para responder a consultas do usuário final. Um projeto bemsucedido deve considerar a demanda desse usuário por empenho rápido. Portanto, em algumas ocasiões, será preciso desnormalizar certas partes de um projeto do banco de dados, de modo a atender às exigências de desempenho. A desnormalização produz uma forma normal mais entanto, o preço a pagar pela melhora de desempenho decorrente da desnormalização é a maior redundância de dados. 2.2.1. Primeira Forma Normal (1FN) O primeiro passo da normalização consta da transformação do esquema de tabela não normalizada em um esquema relacional na primeira forma normal (1FN). Segundo Rob e Coronel (2011), uma tabela encontra-se na 1FN quando: não há grupos de repetição na tabela. Em outras palavras, cada intersecção de linha/coluna contém um e somente um valor, não um V todos os atributos são dependentes da chave primária. CÓDIGO NOME GERENTE DEP. LOCALIZAÇÕES DO DEPARTAMENTO 5 Pesquisa 1 Cachoeiro, Castelo, Muqui 4 Adm eja um exemplo de quando uma tabela não está na 1FN: 1 Sede 3 Iconha 2 Marataízes, Guarapari 2.2.2. Segunda Forma Normal (2FN) Segundo Rob e Coronel (2011), uma tabela encontra-se na 2FN quando: está em 1NF. e dependente apenas de uma parte da chave primária.

48 EROS MOURA Se a 2FN trata das dependências parciais de uma chave primária, se a chave primária for simples (formada apenas por um atributo) ela já estará na 2FN. Observe que ainda é possível uma tabela em 2NF apresentar dependência transitiva, ou seja, um ou mais atributos podem ser funcionalmente dependentes de atributos não relacionados à chave. Veja um exemplo de quando uma tabela não está na 2FN: * A * B C D Ddepende só de A e não da chave inteira (A,B) 2.2.3. TERCEIRA FORMA NORMAL (3FN) Segundo (Rob e Coronel, 2011), uma tabela encontra-se na 3FN quando: está em 2NF. e não contém dependências transitivas. *A B C C depende de B que não é chave Coloque as estruturas abaixo na 3FN. a) Contrato( num_contrato, cod_cliente, dta_inicio_contrato, dta_termino_contrato, num_prestacao, val_prestacao, dta_venc_ prestacao ) b) PecaEstocada(cod_peca, cod_armazem, qtd_estocada, tel_armazem)

BANCO DE DADOS 49 c) Horario_Voo(sigla_cia, num_voo, hor_voo, sigla_aeroporto, nom_aeroporto, cidade_aeroporto, status_voo). OBS: a chave primária está em negrito e sublinhado. 2.2.4. EXEMPLO DE MODELO LÓGICO Veja aqui exemplo de um modelo lógico de uma transportadora. TIPO CLIENTE UF sigla_uf: CHAR(2) nome_uf: VARCHAR(25) CIDADE sigla_uf: CHAR(2) nome_cidade: VARCHAR(40) sigla_uf: CHAR(2) (FK) cod_tipo_cliente: INTEGER descricao_tipo_cliente: VARCHAR(20) ITENS_MANIFESTO num_manifesto: CHAR (6) (FK) num_ctrc: CHAR(6) (FK) posicao_ctrc: INTEGER CTRC num_ctrc: CHAR (6) cliente_remetente: INTEGER (FK) cliente_destinatario: INTEGER (FK) bairro_cliente: VARCHAR(40) data_emissão: CHAR (10) peso_ctrc: NUMERIC (8,2) frete_ctrc: NUMERIC (10,2) Remetente Destinatário CLIENTE cod_cliente: INTEGER nome_cliente: VARCHAR(40) rua_cliente: VARCHAR(40) bairro_cliente: VARCHAR(40) cidade_cliente: INTEGER (FK) cep_cliente: VARCHAR(8) documento_cliente: VARCHAR (20) cod_tipo_cliente: INTEGER (FK) MANIFESTO num_manifesto: CHAR (6) filial_origem_manifesto: CHAR(3) (FK) filial_destino_manifesto: CHAR (3) (FK) placa_veiculo_manifesto: CHAR (7) (FK) data_emissao_manifesto: CHAR (10) data_chegada_manifesto: CHAR (10) cod_ajudante: INTEGER (FK) CTRC_NF num_ctrc: CHAR(6) (FK) num_nf: CHAR(6) MANIFESTO_MOTORISTA num_manifesto: CHAR (7) cod_motorista: INTEGER (FK) CLIENTE_TELEFONE cod_cliente: INTEGER (FK) telefone_cliente: CHAR(10) MOTORISTA cod_motorista: INTEGER nome_motorista: VARCHAR(40) sexo_motorista: CHAR(1) Origem Destino VEICULO placa_veiculo: CHAR (7) descricao_veiculo: VARCHAR (FK) UF sigla_uf: CHAR(2) nome_uf: VARCHAR(25) AJUDANTE cod_ajudante: INTEGER (7) nome_ajudante: VARCHAR (35) Baseado no modelo lógico acima, responda às seguintes perguntas. a) um manifesto pode ter, no mínimo, itens de manifesto e, b) um item de manifesto pode ter, no mínimo, manifesto(s) e, no máximo, manifesto(s). c) um manifesto pode ter, no mínimo, ajudante(s) e, no máximo, ajudante(s).

50 EROS MOURA d) qual é a chave primária da tabela itens manifesto? e) responda a estas perguntas para todos os relacionamentos e chaves primárias do modelo. 2.3. MODELO FÍSICO DE DADOS (MFD) Define-se como modelo físico de dados (também chamado de modelo interno) aquele em que a representação dos objetos é feita sob o foco do nível físico de implementação das entidades e seus relacionamentos. O conhecimento do modo físico de implementação das estruturas de dados é ponto básico para o domínio desse tipo de modelo. Cada diferente SGBD poderá definir um diferente modo de implementação física das características e recursos necessários para o armazenamento e manipulação das estruturas de dados. Utilizar estas características de modo correto pode significar uma ótima performance, enquanto a não utilização das mesmas pode significar um grande problema. Na prática, para se desenvolver um bom modelo físico é necessário um bom conhecimento do SGBD com que você vai trabalhar (aqui, estou me referindo a um específico SGBD, por exemplo, PostGreSQL). Neste momento, você não tem conhecimento necessário para decidir se no SGBD Oracle é melhor trabalhar com a tabela Cliente particionada em vários discos rígidos diferentes ou não. Ou, se para o campo sexo da tabela Cliente, que receberá consultas, seria melhor criar um índice BTree ou Bitmap. Cougo (1997) diz que, em alguns casos, um mesmo SGBD em diferentes ambientes de sistema operacional poderá ter diferentes métodos de armazenamento e manuseio de suas estruturas de dados. Isso é fácil de ser constatado quando analisamos um SGBD que tenha sua implementação, por exemplo, em ambiente Windows(DOS), Linux(UNIX) e VMS. Em cada um desses ambientes, existirão diferentes estruturas de armazenamento, endereçamento, acesso e alocação física. Isso significa que, em alguns casos, um mesmo modelo lógico poderá estar mapeado de diferentes modos em cada um dos sistemas operacionais.

BANCO DE DADOS 51 Baseado no modelo conceitual abaixo, crie o modelo lógico. cod_cidade nome_cidade sigla_uf CIDADE (1,1) (0, n) Está localizada (1,1) sigla_uf UF nome_uf Mora cod_cliente nome_cliente rua numero (1,n) CLIENTE (1,1) bairro cod_cidade cep telefones )(0,n sexo (M,F ) TÉCNICO (1,1) cod_técnico nome_técnico terceitos )(S,N pede faz número_oe data_os hora_os cod_cliente matrícula_atendente descrição_problema descrição_fechamento posição_os (A,F, P) valor_total_os (1,n) Ordem de Serviço (0,n) (1,1) Possui (1,n) (1,n) Serviço Executado (0,n) (0,n) número_os cod_serviço cod_técnico data_inicial_serviço hora_inicial_serviço data_final_serviço hora_final_serviço valor_cobrado_serviço Cadastra data_uso hora_uso usa é feito quantidade_uso (1,1) ATENDENTE (1,1) matrícula_atendente nome_atendente ESTOQUE SERVIÇO quantidade_estoque cod_serviço nome_serviço estimativa_tempo valor_serviço valor_compra desc_estoque cod_estoque