Modelagem de Dados Aula 3

Capítulo 4 – Abordagem Relacional Este capítulo detalha como um banco de dados relacional é organizado (que estruturas de dados são usadas, como elas estão relacionadas), mas não discute como um banco de dados relacional pode ser modificado ou acessado, ou seja não apresenta as linguagens de manipulação de dados, como por exemplo, SQL. Roteiro: Composição de um BD Relacional (páginas 78 a 84) Tabelas Chaves Domínio e Valores Vazios Restrições de Integridade Especificação de BD Relacional (página 84) Consulta a Base de Dados (página 85)

Abordagem Relacional Além dos SGBD relacionais, existem outros tipos de sistemas no mercado. Entretanto, hoje há um claro predomínio dos SGBD relacionais, principalmente fora das plataformas de grande porte. Mesmo nestes ambientes, os SGBD relacionais estão gradativamente substituindo os SGBD de outras abordagens (hierárquica ou rede). Além disso, muitos conceitos usados no projeto de BD, como, o conceito de normalização, foram criados em combinação com a abordagem relacional. Exemplos de SGBD relacionais: Oracle 9i (Oracle) SQL Server 2000 (Microsoft), MySQL 3.23(MySQL), DB2 8.1 (IBM).

Abordagem Relacional Linguagens de Programação SGBD 1º Geração (45): Máquina/Assembly 2º Geração (50/60): Fortran/Cobol/Basic (68) Hierárquico: IMS 3º Geração (70): Pascal/Java/C++/Delphi (71) Rede: IDMS 4º Geração (74): SQL (74) Relacional: SEQUEL-XRM (77) Relacional: SYSTEM/R (79) Relacional: ORACLE (80) Relacional: DB2/SQL

Composição de um BD Relacional Um banco de dados relacional é composto de tabelas ou relações, baseando-se no princípio de que as informações em uma base de dados podem ser consideradas como relações matemáticas e que estão representadas de maneira uniforme, através do uso de tabelas bidimensionais (linhas x colunas). Este princípio coloca os dados dirigidos para estruturas mais simples de armazenar dados, as tabelas, nas quais a visão do usuário é privilegiada. Os usuários percebem os dados como tabelas (e nada mais do que tabelas) e os operadores à disposição do usuário (por exemplo, para a consulta de dados) são operadores que geram novas tabelas a partir das antigas.

Tabelas Uma tabela é um conjunto não ordenado de linhas (tuplas). Cada linha é composta por uma série de campos (atributos). O conjunto de campos de todas as linhas de uma tabela formam uma coluna. Tupla - Informações referentes a um mesmo elemento. No banco de dados de alunos, informações como o número da matrícula, nome, endereço, data de nascimento, etc. formam uma tupla. Nas tabelas, as tuplas são representados por linhas. Tupla corresponde à definição de registro. Atributo - Cada um dos espaços reservados para informações em um banco de dados. Por exemplo, em um banco de dados de alunos, Nome é um atributo e Endereço é outro. Nas tabelas, os atributos são representados por colunas. Atributo corresponde à definição de campo.

Tabelas Um grupo de tuplas que, por sua vez, representa um grupo de atributos. Ela é uma coleção de dados que têm a mesma estrutura. Por exemplo, uma tabela usada pela secretaria de um colégio pode conter informações completas sobre cada um dos alunos. As tabelas possuem propriedades que são as seguintes: As linhas não seguem um ordenamento (de cima para baixo); Os atributos não seguem um ordenamento (da esquerda para a direita); Não há tuplas duplicatas; Todos os valores de atributo são simples (atômicos e monovalorados.

Chaves Entre os atributos de uma tabela, existe alguns com propriedades especiais conhecidos como chaves, que equivale ao conceito de identificadores no modelo E-R, através destas chaves ligamos logicamente as tabelas no banco de dados relacional. O conjunto de um ou mais atributos com a propriedade de identificar unicamente os elementos de uma tabela é denominada chave primária. Por exemplo, o atributo chave, capaz de identificar um aluno específico dentro de um colégio é o número da matrícula, mas para identificar um aluno dentro de uma turma a chave “ideal” é o número da chamada. Ao escolher a chave primária, poderá existir mais de uma opção na relação, essas opções são as chaves candidatas.

Chaves Por definição, toda tabela tem, pelo menos, uma chave candidata; na prática, a maioria das relações têm exatamente uma, mas é possível que algumas tenham duas ou mais. Para uma determinada relação, se escolhe uma das chaves candidatas para ser a chave primária, e então as restantes (se houver), são chamadas de chaves alternativas. No banco de dados relacional quando dizemos que duas tabelas estão relacionadas através de atributos comuns, devemos observar que provavelmente esta coluna em uma das tabelas é uma chave primária. Na outra tabela, este conjunto de um ou mais atributos que são chaves primárias de outra tabela é denominado de chave estrangeira.

Chaves A existência de uma chave estrangeira impõe restrições que devem ser garantidas ao executar diversas operações de alteração do banco de dados: Quando da inclusão de uma linha na tabela que contém uma chave estrangeira deve ser garantido que o valor da chave estrangeira apareça na coluna da chave primária referenciada. Quando da alteração do valor da chave estrangeira deve ser garantido que o novo valor de uma chave estrangeira apareça na coluna da chave primária referenciada. Quando da exclusão de uma linha da tabela que contém a chave primária referenciada pela chave estrangeira deve ser garantido que na coluna da chave estrangeira não apareça o valor da chave primária que está sendo excluída.

Domínios e Valores Vazios Chaves Quando da alteração do valor da chave primária referenciada pela chave estrangeira deve ser garantido que na coluna da chave estrangeira não apareça o antigo valor da chave primária que está sendo alterada. Domínios e Valores Vazios Quando uma tabela do banco de dados é definida, para cada coluna da tabela, deve ser especificado um conjunto de valores (alfanumérico, numérico,..) que os campos podem assumir. Este conjunto de valores é chamado de domínio da coluna ou domínio de campo.

Domínios e Valores Vazios Além disso, deve ser especificado se os campos da coluna podem estar vazios (null) ou não. Estar vazio indica que o campo não recebeu nenhum valor de seu domínio. As colunas nas quais não são admitidos valores vazios são chamadas obrigatórias. As colunas nas quais podem aparecer campos vazios são chamadas de colunas opcionais. Normalmente, os SGBD relacional exigem que todas colunas que compõem a chave primária sejam obrigatórias. A mesma exigência não é feita para as demais chaves (estrangeiras e alternativas).

Restrições de Integridade Um dos objetivos primordiais de um SGBD é a integridade de dados. Dizer que os dados de um banco de dados estão íntegros significa dizer que eles refletem corretamente a realidade representada pelo banco de dados e que são consistentes entre si. Para tentar garantir a integridade de um banco de dados os SGBD oferecem o mecanismo de restrição de integridade. Uma restrição de integridade é uma regra de consistência de dados que é garantida pelo próprio SGBD. No caso da abordagem relacional, costuma-se classificar as restrições de integridade nas seguintes categorias: Integridade de Domínio especifica que o valor de um campo deve obedecer a definição de valores admitidos para a coluna (domínio da coluna).

Restrições de Integridade Integridade de Vazio especifica se os campos podem ou não ser vazios. Os campos que compõem a chave primária não podem ser vazios. Integridade de Chave especifica que os valores da chave primária e alternativa devem ser únicos. Integridade Referencial especifica que os valores dos campos que aparecem em um chave estrangeira devem aparecer na chave primária da tabela referenciada. As restrições dos tipos acima especificados devem ser garantidas automaticamente por um SGBD relacional, isto é, não deve ser exigido que o programador escreva procedimentos para garanti-las explicitamente. Há muitas outras restrições de integridade que não se encaixam em nenhuma das categorias acima e que normalmente não são garantidas pelo SGBD. Essas restrições são chamadas restrições semânticas.

Especificação de BD Relacional A especificação de um banco de dados relacional (chamada de esquema do banco de dados) deve conter no mínimo a definição do seguinte: tabelas que formam o banco de dados, colunas que as tabelas possuem e as restrições de integridade. Abaixo apresentaremos uma notação resumida, onde são listadas as tabelas e, para cada tabela, enumerados, entre parênteses, os nomes das colunas que compõem a tabela. As colunas que compõem a chave primária aparecem sublinhadas. Após a definição da tabela aparecem as definições das chaves estrangeiras existentes. Notação: <nome de tabela1> (<nome de coluna1 ch primária>,<nome de coluna2,...) <nome de tabela2> (<nome de coluna1 ch primária>,<nome de coluna2,...) (<nome de coluna1 ch estrangeira>, <nome de coluna2 ch estrangeira>...) referencia <nome de tabela>

Consulta à Base de Dados Para realizar uma consulta a um banco de dados relacional, utilizamos a linguagem SQL, linguagem padrão de definição e manipulação de banco de dados. Na instrução SQL, o programador não faz referência a nenhum tipo de caminho de acesso. Quem decide que caminhos de acesso serão eventualmente usados quando da execução da instrução é o SGBD. Quando em uma instrução estão envolvidas duas tabelas, associação entre linhas das duas tabelas é feita normalmente por uma operação chamada de junção.

Capítulo 5 -Transformações entre Modelos Nos capítulos anteriores, mostramos duas formas de modelagem de dados, a abordagem ER e a abordagem relacional. Estas abordagens propõe modelar os dados em diferentes níveis de abstração. A abordagem ER é voltada à modelagem de dados de forma independente do SGBD considerado. É adequada para construção do modelo conceitual. Já a abordagem relacional modela os dados a nível de SGBD relacional, sem se preocupar qual o SGBD irá implementar. Um modelo neste nível de abstração é chamado de modelo lógico. No presente capítulo, vamos considerar a relação entre estes dois níveis de modelagem.

Capítulo 5 -Transformações entre Modelos Inicialmente, vamos apresentar o projeto lógico de BD relacional. O projeto lógico consta da transformação de um modelo ER em um modelo lógico, que implementa, a nível de SGBD relacional, os dados representados abstratamente no modelo ER. O termo “implementação” significa que ocorre uma transformação de um modelo abstrato para um modelo que contém mais detalhes de implementação. Para outros tipos de SGBD (p.ex.: orientado a objetos ou objeto/relacional) outras regras de projeto são necessárias. A seguir, vamos apresentar o processo inverso ao projeto, que é chamado de engenharia reversa de BD relacional. Neste processo, parte-se de um modelo relacional e obtém-se um diagrama ER, que representa de forma abstrata os dados armazenados no BD.

Capítulo 5 -Transformações entre Modelos Roteiro: Visão Geral do Projeto Lógico (páginas 90 a 91) Transformação ER para Relacional (páginas 91 a 93) Implementação inicial de entidades (páginas 93 a 96) Implementação de relacionamentos (páginas 96 a 98) Detalhes de implementação de relacionamentos (páginas 98 a 105) Implementação de generalização/especialização (páginas 105 a 111) Refinamento do modelo relacional (páginas 111 a 115) Engenharia Reversa de Modelos Relacionais (páginas 115 a 116) Identificação da construção ER correspondente a cada tabela (páginas 116 a 117) Identificação de relacionamentos 1:n ou 1:1 (páginas 117 a 118) Definição de atributos (página 118 ) Definição de identificadores (página 118)

Transformações entre Modelos engenharia reversa de BD relacional projeto lógico modelo ER (nível conceitual) modelo relacional (nível lógico)

Visão Geral do Projeto Lógico refinamento do modelo relacional transformação ER para relacional modelo ER (nível conceitual) (nível lógico) conhecimento sobre a aplicação

Transformação ER para Relacional Existem regras precisas que não dão margem a erros, sendo que uma vez projetado o modelo E-R, as tabelas que o representam podem ser obtidas de forma clara. É evidente que nesta passagem devem ser observadas as características do SGBD que será utilizado, pois existem diferenças que podem auxiliar ou dificultar algumas soluções propostas. Alguns SGBD’s necessitam de adaptações específicas. Toda entidade torna-se uma tabela carregando todos os atributos (definidos para a entidade). Cada atributo vira um campo da tabela criada e o atributo identificador se torna a chave primária. O relacionamento com cardinalidade muitos para muitos também torna-se uma tabela carregando os atributos (se houver) e os identificadores das tabelas (entidades) que ele se relaciona.

Transformação ER para Relacional As regras foram definidas tendo em vista estes objetivos: Obter um banco de dados que permita boa performance de instruções de consulta e alteração do banco de dados. Obter boa performance significa basicamente diminuir o número de acessos a disco, já que estes consomem o maior tempo na execução de uma instrução de banco de dados. Obter um banco de dados que simplifique o desenvolvimento e a manutenção de aplicações. Obter um banco de dados que ocupe pouco espaço em disco. O objetivo de reduzir espaço de armazenamento diminuiu de importância com a diminuição dos preços dos meios de armazenamento.