PDF Tecnologias de Bases de Dados

```markdown ## 172 TECNOLOGIAS DE BASES DE DADOS ### 13.1. O MODELO RELACIONAL DE BASES DE DADOS ### Bases de dados e tabelas The image shows a diagram that contrasts "common language in databases" with the "formal language of the relational model", highlighting that the common language equivalent...

```markdown ## 172 TECNOLOGIAS DE BASES DE DADOS ### 13.1. O MODELO RELACIONAL DE BASES DE DADOS ### Bases de dados e tabelas The image shows a diagram that contrasts "common language in databases" with the "formal language of the relational model", highlighting that the common language equivalent of a "table" is a "relation", and showing the analogy between attributes and columns. |Linguagem comum nas bases de dados| Tabela| Linguagem formal do modelo relacional| |---|---|---| |Colunas ou campos| |Atributos| ||1 Abel Lisboa|| |Nome|Aluno|| |Linhas ou registos|2 Ana Porto|Tuplos| |N_Aluno||| ||3 Carla Coimbra|| |Morada|||| ||4 Daniel Funchal|| **FIG. 13.1.** As entidades dos diagramas ER ou as classes dos diagramas de classes vão corresponder a tabelas de bases de dados em que os atributos dão origem aos campos ou colunas dessas tabelas. ### Base de dados Uma base de dados pode ser definida como um conjunto estruturado de dados armazenado num suporte informático, de uma forma acessível à consulta e manipulação por parte dos utilizadores. O software que permite criar e/ou gerir uma base de dados costuma ser designado por **SGBD - Sistema de Gestão de Bases de Dados**. Um SGBD é concebido para poder implementar bases de dados segundo um determinado modelo. Desde a década de 80 que o modelo de bases de dados mais difundido e utilizado nos sistemas de informação e em geral é o modelo relacional. O modelo relacional foi criado por um grupo de trabalho dirigido por Edgar Codd, cerca de 1970. Neste modelo, a estrutura básica é a tabela, que é vista como uma relação de dados. Foi a palavra inglesa _relation_ que deu origem ao nome do modelo relacional e não, ao contrário do que por vezes se pensa, as relações ou relacionamentos (_relationship_, em inglês) entre as tabelas, que também são uma característica fundamental deste modelo. ### Tabelas Uma tabela é uma estrutura de dados formada por: 1. Um conjunto de colunas, campos ou atributos (tudo sinónimos); 2. Um conjunto de linhas, registos (ou ainda tuplos, na linguagem do modelo relacional). Como é fácil de constatar, uma tabela é uma estrutura de dados para armazenar informação sobre uma entidade ou classe, no sentido em que definimos estes termos no módulo anterior (capítulo 12.2. Modelação de dados). Na verdade, quando falámos de entidades (diagramas ER) e de classes (diagramas de classes), já tínhamos em vista que tanto umas como outras vão, em princípio, dar origem a tabelas de bases de dados (ver figura 13.1). ##. ## 13.1.0 MODELO RELACIONAL DE BASES DE DADOS The image shows a Domains of Attributes diagram with examples of the values or data types that each attribute or field of the table can assume. |Atributos ou campos| |---| |NAluno Nome Localidade| |1 Abel Lisboa| |2 Ana Porto| |3 Carla Coimbra| |4 Daniel Funchal| **FIG. 13.2.** Os domínios dos atributos (ou campos) correspondem aos tipos de dados que eles podem assumir. ### Atributos e campos Vimos que quer uma entidade quer uma classe são formadas por atributos. Vimos também que um atributo é uma propriedade ou característica de uma entidade que nos interessa registar num sistema ou base de dados. Nas bases de dados do modelo relacional, os atributos correspondem às colunas de uma tabela que também costumam ser designadas por campos. Por exemplo, na figura 13.1 ou 13.2, a tabela Alunos contém o seguinte conjunto de campos: N_Aluno; Nome; Localidade. ### Registos Por sua vez, as linhas de uma tabela correspondem a registos. Por conseguinte, um registo é constituído por um conjunto de dados (atributos ou campos) relativos a uma entidade singular ou um objeto. Por exemplo, na tabela Alunos da figura 13.1 ou 13.2, o conjunto dos dados (2, Ana, Porto) é um registo dessa tabela. ### Domínios dos atributos Um outro conceito muito importante que está relacionado com cada atributo (ou campo) de uma tabela é o de domínio. Como também já vimos (e se representa aqui de novo na figura 13.2), o domínio de um atributo (ou campo de uma tabela) corresponde aos valores ou tipos de dados que esse atributo (ou campo) pode assumir. Por exemplo, no campo N_Aluno, o domínio corresponde aos números inteiros que podem ser atribuídos aos alunos. Por sua vez, o campo Nome terá como domínio o conjunto dos nomes possíveis. O campo Localidade terá como domínio os nomes possíveis de localidades, etc. Como é fácil de ver, os domínios são importantes para a definição da estrutura de uma tabela, pois têm a ver com os tipos de dados com que um sistema informático e um SGBD pode trabalhar, tais como inteiros, reais, datas, _strings_, etc. ## 174 TECNOLOGIAS DE BASES DE DADOS ### Tabelas em bases de dados relacionais |Tabela Alunos|Chaves candidatas||Tabela Artigos|Chave candidata?| |---|---|---|---|---| |N_Aluno|Nome|Localidade|Designação|Categoria|Preço| |1|Abel Silva|Lisboa|Portátil PP|Computadores|400| |2|Ana Nunes|Porto|Impressora X|Periféricos|100| |3|Carla Dias|Porto|Impressora Y|Periféricos|200| |4|Eva Silva|Lisboa|Tinteiro|Consumíveis|20| |Chave primária|||Chave primária?|| **FIG. 13.3.** Chaves candidatas e chave primária. Na tabela Alunos, temos duas chaves candidatas (N_Aluno e Nome). O campo N_Aluno foi selecionado para ser a chave primária. Na tabela Artigos, há apenas uma chave candidata: Designação (que não oferece garantias de não conter dados repetidos). Em situações como esta, o melhor é criar um campo de código para funcionar como chave primária. ### Chave primária e chaves candidatas No modelo relacional, para que uma tabela esteja bem definida deve, em princípio, ter uma chave primária. Uma _chave primária_ é um atributo ou conjunto de atributos que permite identificar de forma unívoca cada registo numa tabela, sendo selecionado para esse efeito entre as possíveis chaves candidatas. Uma _chave candidata_ é um atributo ou conjunto de atributos que permite identificar de forma unívoca cada registo numa tabela. Os dois conceitos são semelhantes; a única diferença é que a chave primária é selecionada entre as chaves candidatas para desempenhar essa função de identificar de forma unívoca cada registo numa tabela. Para compreendermos o significado deste conceito, vejamos as tabelas apresentadas na figura 13.3. Para que um atributo possa ser chave candidata não pode conter dados repetidos em diferentes registos (linhas da tabela) – só assim pode identificar de forma única cada registo. Na tabela Alunos, os atributos que podem ser considerados chaves candidatas são: N_Aluno (número) e Nome. Localidade não pode, porque apresenta dados repetidos. Entre as duas chaves candidatas da tabela Alunos (N_Aluno e Nome), a melhor opção para chave primária é N_Aluno, pois cada aluno terá um número único. O atributo Nome não é tão seguro quanto a esse aspeto, já que é possível surgirem nomes idênticos para alunos diferentes. Na tabela Artigos, tal como está apresentada, temos apenas uma chave candidata: Designação. Os outros campos apresentam dados que se repetem; logo, não podem ser chaves candidatas. Mas, mesmo o campo Designação não oferece garantia de não conter repetições para certos produtos. Em situações como esta, é prática usual criar um campo que ofereça essa garantia. Por exemplo, na tabela Artigos, podemos incluir um campo com um código para o produto (_CodArtigo_ ou algo semelhante) e, então, passará esse campo a ser a chave primária da tabela. ## ## 13.1.0 MODELO RELACIONAL DE BASES DE DADOS 17 Diagram of tables in structural view in MS Access and diagrams showing data types on the other **FIG. 13.4.** Uma tabela na vista de estrutura no MS Access. ### Formas de representar uma tabela numa base de dados relacional As tabelas dos exemplos que vimos até aqui estão todas no seu formato mais habitual de um conjunto de colunas por um conjunto de linhas. Este formato de tabela também é, por vezes, designado por folha de dados ou vista de folha de dados. No entanto, também é prática habitual representar as tabelas de uma base de dados relacional através de outras formas convencionais. Na figura 13.4, temos uma tabela na vista de estrutura no SGBD MS Access. Na figura 13.5, temos uma tabela na vista de estrutura definida tecnicamente, antes de implementação num sistema de bases de dados. Neste caso, a tabela "Sócios" está representada em vista de estrutura ou definição de estrutura porque temos apenas as definições técnicas dos campos dessa tabela (sem a "folha de dados"). Essas definições técnicas dos campos da tabela assemelham-se a entradas de um dicionário de dados para uma tabela de uma base de dados. Cada campo da tabela inclui, após o respetivo nome, a indicação do seu tipo de dados, bem como outras indicações importantes, como se é chave primária, se é um campo de preenchimento obrigatório, valores _default_, valores opcionais, etc. Por exemplo, o campo Número está indicado como sendo do tipo _Integer_ (inteiro) e $<<PK>>$, que quer dizer _Primary Key_, ou seja, chave primária. No campo Sexo, é indicado _Char_ (carácter) e são explicitadas as únicas opções aceitáveis $\["M"|"F"]$ - caracteres Mou F. Há ainda uma outra forma de representar uma tabela, chamada representação analítica, que é uma forma simplificada da vista de estrutura. Considerando o exemplo anterior da tabela Sócios, ela também pode ser representada assim: Sócio (Número, Nome, Sexo, DataNascimento, Morada) Neste caso, indica-se o nome da tabela, seguido da lista de atributos ou campos, dentro de parênteses curvos. O facto de o campo Número estar sublinhado indica que se trata da chave primária desta tabela. ## 170 TECNOLOGIAS DE BASES DE DADOS ### Relacionamentos entre tabelas Illustration showing the relationship between two tables. **FIG. 13.6.** Exemplo de um relacionamento entre duas tabelas. O campo CodForn, que é chave primária na tabela Fornecedor, aparece na tabela Artigo, onde toma o lugar de chave estrangeira. As bases de dados relacionais raramente consistem numa só tabela. O grande sucesso do modelo relacional deve-se ao facto de podermos combinar, numa mesma base de dados, uma multiplicidade de tabelas. Recordemos que os diagramas ER ou de classes se caracterizam por nos mostrarem como as entidades ou classes podem relacionar-se entre si. Consideremos, por exemplo (ver figura 13.6), a situação de uma empresa que comercializa um conjunto de artigos (tabela Artigo), que compra aos seus fornecedores (tabela Fornecedor). Num diagrama de classes, o relacionamento entre as duas entidades ou classes (tabelas) pode ser representado como é apresentado na parte superior da figura 13.6 e se reproduz aqui. The illustration shows the relationship between Article and Supplier tables. In the Article table, the CodForn field, which is the primary key of the Supplier table, is included. **FIG. 13.7.** Relacionamento entre Artigo e Fornecedor. Na tabela Artigo, foi incluído o campo CodForn que é a chave primária da tabela Fornecedor. A questão que agora se coloca é: como é que esse relacionamento se traduz para uma base de dados relacional? Na versão apresentada na figura 13.6, esse relacionamento está traduzido da seguinte forma: * Na tabela Artigo, foi incluído um campo - CodForn - que corresponde à chave primária da tabela Fornecedor; nesse campo são registados os códigos correspondentes aos fornecedores. Numa situação como esta, estamos perante o que se chama uma chave estrangeira (_FK - Foreign Key_). Uma chave estrangeira é um campo "importado" para uma tabela, sendo chave primária na tabela de origem. Esta é a forma de estabelecer relacionamentos entre tabelas numa base de dados relacional. Consideremos como tabela principal aquela que contém a chave primária a ser importada (no nosso exemplo, é a tabela Fornecedor); e consideremos como tabela relacionada aquela que recebe a importação da chave primária - que, nesta tabela que a recebe, passa a ser referida como chave estrangeira. ## 13.1.0 MODELO RELACIONAL DE BASES DE DADOS 171 The image shows an example of a relationship between two entities or tables that passes through a third entity or association table. The diagram shows two entities, Departamento and Empregado, connected by a table named Depart_Empreg. **FIG. 13.8.** Exemplo de um relacionamento entre duas entidades ou tabelas que passa por uma entidade ou tabela de associação. CPTGPSI815 Porto Editora Às vezes, o relacionamento entre duas tabelas (entidades ou classes) passa por uma terceira tabela (entidade ou classe) de associação (para este assunto, rever as páginas 162-163). Consideremos, por exemplo, a situação de uma empresa (ver figura 13.8), em que os empregados estão ligados aos vários departamentos da empresa na seguinte relação: * Cada empregado pode trabalhar em zero ou vários departamentos (0..*) e cada departamento pode ter um ou vários empregados (1..*); como os empregados podem passar de um departamento para outro, interessa registar a data de entrada em departamento manter esses registos ao longo do tempo. Em situações como esta, não funciona importar a chave primária da tabela principal (neste caso, Departamento) para A tabela (Departamento). o outra Não podemos, simplesmente, colocar na tabela Empregado o código do Departamento, pois pode haver empregados, que não estão ligados a nenhum departamento_ além disso, interessa registrar o Departamento, também é um para a outro os Em situações como esta solução para criar tabela: * relacionamento (cidade ou de No nosso exemplo, uma tabela criada com 0 * para do relacionamento, como dois departamentos empregados Na tabela: 1. Cod. é uma linha Departamento, portanto uma a: 2. que é também uma linha de desta empresa, é o Desta forma, uma tabela, em para cada Departamento. em na * chave de: Codp CodDep . ## 178 TECNOLOGIAS DE BASES DE DADOS ### Integridade da informação numa base de dados relacional O modelo relacional obriga a que a realização das operações de atualização numa base de dados decorra de forma consistente. A manutenção da consistência ou integridade da informação numa base de dados deve ser assegurada pelo SGBD (ou pelas aplicações que forem criadas para aceder à base de dados). Uma base de dados relacional deve assegurar dois tipos de integridade: 1. integridade de entidade; 2. integridade referencial. ####A integridade de entidade A integridade de entidade impõe que os valores dos atributos que correspondem à chave primária de uma entidade não podem ser nulos nem iguais a outros já existentes na tabela. A introdução de um valor nulo numa chave primária ou a inclusão nessa chave de um valor igual a outro já existente faria com que a chave deixasse de identificar de modo unívoco os registos da tabela; portanto, deixaria de poder funcionar como chave primária. ####A integridade referencial A integridade referencial impõe que um valor de uma chave externa exista obrigatoriamente como elemento constituinte da chave primária da tabela relacionada com aquela chave externa. Uma chave externa, como sabemos, referencia uma entidade existente numa outra tabela (onde é chave primária). Por conseguinte, sempre que é introduzido um valor num campo que é chave externa de uma tabela, o sistema (SGBD ou aplicação) tem de certificar-se que esse valor existe na chave primária da tabela referenciada por aquela chave externa; caso contrário, a base de dados passaria a ter uma inconsistência ou uma falha de integridade referencial (ver exemplos das figuras 13.9 e 13.10). **The image shows a diagram that illustrates the violations of referential integrity.** |Clientes||Artigos|| |---|---|---| |CodCliente|Nome|Morada|CodArtigo|Artigo|CodFornec| |C101|ABC|Porto|1011|Modem|101| |C102|DEF|Lisboa|1022|Scanner|102| |C103|GHI|Faro|1033|Teclado|102| A ? mark indicates the need to verify the existence of the key. |Encomendas|| |---|---| |Nº Encom|DataEncom|CodCliente|CodArtigo|Quantidade| |1|2010-10-10|C101|1022|1| |2|2010-10-10|C103|1011|3| |3|2010-10-11|C102|1033|5| |4|2010-10-11|C130|155|1| The diagram displays a scenario in a database where the "Encomendas" table contains data that references entries in "Clientes" and "Artigos" tables. The violations are indicated when an enconmenda is introduced which does not exist in the tables of Clientes ou artigos. **FIG. 13.9.** Exemplificação de violações da integridade referencial: 1 - a introdução, na tabela Encomendas, de um cliente com o código C130 que não existe na tabela Clientes; 2 - a introdução, na tabela Encomendas, de um artigo com o código 155, que não existe na tabela Artigos. **FIG. 13.10.** Exemplificação de violações da integridade referencial: 1 - a eliminação de um registo na tabela Clientes com o código C103, ficando uma ou mais referências a esse cliente na tabela Encomendas; 2 - a alteração, na tabela Artigos, do código do artigo 1033 para 1035; na tabela Encomendas ficariam referências a um artigo (com o código 1033) não conforme com a tabela Artigos a que se refere. The diagram displays a scenario in a database where the "Encomendas" table shows data that references in "Clientes" and "Artigos". The violations are indicated when an enconmenda is referenced that has been eliminated or is missing in the Clientes ou artigos table. Por outro lado, sempre que quisermos apagar ou alterar um registo numa tabela e esse registo estiver relacionado com registos de outra tabela, estamos perante uma outra possibilidade de violação da integridade referencial - ficarmos com registos que referenciam um registo que deixou de existir. Vejamos, através de exemplos concretos, alguns casos típicos de violação da integridade referencial. 1. Na tabela Encomendas da figura 13.9, pretendemos introduzir um registo, em que o campo CodCliente tem o valor C130. Estamos perante um caso de violação da integridade referencial. O campo CodCliente é chave externa na tabela Encomendas e chave primária na tabela Clientes; ora, nesta última, não existe nenhum registo com o código C130; portanto, a informação que pretendíamos introduzir tem uma falha de integridade referencial. 2. Na tabela Clientes da figura 13.10, pretendemos eliminar um registo correspondente ao artigo com o código C103. Se o fizermos, o que é que acontece aos registos da tabela Encomendas que dizem respeito a esse artigo? Se os mantivermos, estamos a criar uma falha de integridade referencial (a tabela Encomendas tem registos que referenciam artigos que não existem na respetiva tabela). 3. Na tabela Artigos (figura 13.10), pretendemos alterar o artigo com o código 1033 para 1035. Também aqui desaparece um valor (1033) numa tabela (Artigos), enquanto numa outra tabela (Encomendas) continuam a existir registos que fazem referência a esse valor. O SGBD ou a aplicação que estiver a gerir a base de dados devem estar preparados para evitar estas situações em que a informação perde consistência ou integridade referencial, enviando mensagens ao utilizador que lhe permitam retificar a operação. ## 180 TECNOLOGIAS DE BASES DE DADOS ### 13.2. CONVERSÃO DE DIAGRAMAS ER OU DE CLASSES PARA O MODELO RELACIONAL Diagrams ER showing entities (for example, Fornecedor and Artigo) and the corresponding class diagram. **FIG. 13.11.** Diagrama ER (em cima) e diagrama de classes (em baixo) na fase de modelação conceptual da base de dados. CPTGPSI815 Porto Editora ### Introdução Como vimos, os diagramas ER e os diagramas de classes foram concebidos para representar as entidades ou classes importantes para um sistema de informação (SI) ou uma base de dados (BD). A questão importante que agora se coloca é saber como utilizar os diagramas ER ou de classes para elaborar o modelo de uma base de dados relacional - isto quer dizer: desenhar um modelo (ou esquema) com as tabelas da base de dados, incluindo, para cada tabela, os campos que a constituem, as chaves primárias de cada tabela, as chaves estrangeiras necessárias às relações entre as tabelas, etc. Consideremos, a título de exemplo, uma situação muito simples, em que temos apenas as entidades Fornecedor e Artigo e em que um fornecedor pode fornecer um ou vários artigos e um artigo pode ser fornecido por zero ou vários fornecedores. Na figura 13.11, temos o diagrama ER (em cima) e o diagrama de classes (em baixo) correspondente a esta situação. Daqui até à implementação da base de dados relacional (num SGBD) é costume considerarem-se três fases sucessivas. ### Modelo conceptual da BD Esta fase corresponde aos diagramas ER ou de classes apresentados na figura 13.11. Nesta fase apresentam-se apenas as entidades principais a ter em conta para a elaboração da base de dados e, opcionalmente, os atributos mais importantes dessas entidades. O modelo conceptual deve representar a base de dados de uma forma independente do SGBD em que vier a ser implementada. ### Modelo lógico da BD Esta fase resulta de um maior detalhe dos diagramas elaborados na fase anterior, tendo já em vista o modelo de base de dados e o SGBD que se vai adotar. Nesta fase, o modelo lógico da base de dados já tem de ser desenhado de acordo com o modelo relacional de bases de dados (sendo este o modelo que se adotou, como acontece na maior parte dos casos). Isto implica que devem ser explicitados todos os atributos de cada entidade, bem como o atributo que vai funcionar como chave primária (ver figura 13.12). ## 13.2. CONVERSÃO DE DIAGRAMAS ER OU DE CLASSES PARA O MODELO RELACIONAL 181 The illustration shows that the entities and the attributes related to the ER and the class diagram in the model logical phase. **Diagrama ER (à esquerda) e diagrama de classes (a direita) na fase do modelo lógico da bases de dados.**. ### Modelo fisico da BD Na fase do modelo físico da base de dados as entidades do modelo lógico são convertidas em tabelas (na sua representação da estrutura). Aquí, já é necesario ter em conta todas regras de funciamento dos SGBD relacionais; Por exemplo, uma questão importante é que esses sistemas não permitem uma relación com 3 ou 4 sistemas. ### Para o modelo físico corresponde á seguinte descrição analíca: 1. Fornecedor (CodeForn,Nome,Morada); 2 Artigo (CodeArt,Designação, ### Nota: A char é formar (conheça) Forneceodor 1.1 Artigo Codefern 1.1 CodeArt Nome Design Morada. Type * - Diagrama com 0 MODELO FÍSICO DA BASA DE DADOS. ## 182 TECNOLOGIAS DE BASES DE DADOS ### Regras de conversão de relacionamentos para o modelo relacional Nesta secção vamos apresentar um conjunto de situações de relacionamentos binários típicos quanto à cardinalidade e participação das entidades. Como já havíamos referido na página 157, estas situações influem no número de tabelas necessárias, bem como nos seus campos, chaves primárias e chaves estrangeiras. É isso que vai ser aqui analisado. ### Situação 1 Relacionamento binário do tipo 1:1 (um--para-um) com participação obrigatória das duas entidades {(1..1) : (1..1)} Modelo Lógico - Diagrama ER ### Situação 2 Relacionamento binário do tipo 1:1 (um--para-um) com participação obrigatória em apenas uma das duas entidades {(1..1) : (0..1)} Modelo Lógico - Diagrama ER ### Modelo Lógico - Diagrama de Classes ### Modelo Lógico - Diagrama de Classes 1..1 Classe B b1 \<\<CK>> ### Modelo Lógico - Diagrama de Classes 1..1 Classe B b1 \<\<CK>>= (b2) = FIG. 13.14. ### The illustration shows some conventions 1-Indication of classes (00) 2- Chaves dos Clasos Ck 3- Chaves de Neste primeiro modelo ### Situação 4 Os principais pontos ### The Image shows Entidade A:0.1 A1 Entidade: 0.1 B1 Todos os modelos tem que ter: 1. 23 pontos e A a e a dos 1 .1 ## 13.2. CONVERSÃO DE DIAGRAMAS ER OU DE CLASSES PARA O MODELO RELACIONAL 183 ### The illustration shows some relations Entidade: 1.1 A->A1 Entidade 1.1 B->B1 ### Os principais Todos os modelos tem que ter: 12 e 22 23 o e Para poder ajudar precisa se de 1,1 Entidade a Entidade 1 a 1 FIG. 13: 18 Todos os modelos tem que ter a b e 1.1 Sendo que todos tem sempre por ter entre os 3 e 1,1 ### Neste caso são necesarios. Modelo A->A1 ## 184 TECNOLOGIAS DE BASES DE DADOS A illustração a e b ### A chave nos ajuda B-> 1.1 e 1.1 Todos sempre 1. Um a um para Todos A a 11A b11B a d 00 Compara nos o modelo modelo ####Todos São necesario tres tables ou. 1.1 modelo A -A1 1.1 B->B1 0.1 ####A sua pode. 1.1 ## 185 Essa 01 11 com 11 A b a sua para um 1 b a e ### As necessitas ## 186 Modelo conceptual a fisico The diagram presents a simplified database for a library. There are examples of -Diagrams ER. -Diagram Classes ### SUPONHAMOS QUE 1322 com modelo para base de dados da bliblioteca Quremos a Livros e a Autores P. 0 precisamos a Utentes da bliblioteca ### Os que fazemos Livro UTENTES CADA UTENTE DE 0 varios requiaisoes de livros CADA um livro varias vezes. Todos os casos. ## Conclussão Modelo a Autores_ Utentes Os SGBD NÃO a ## 187 ### Os diagramas das classes E indica Utentes de Na E tambem classes autores livros #### O que fazemos 1 UTENTE #### Encontrar modelo físico à ##### Utlizar 1. utentes (nomes) #### Deixar a ter ##### Modelo final ### O exemplo Livro com Autores ou A para utentes ##### utentes e dados Com a a d Final os dados ## 188 TECNOLOGIAS DE BASES DE DADOS ### 13.3. NORMALIZAÇÃO DE UMA BASE DE DADOS RELACIONAL The diagram presents a simplified database . The diagram is shown step by step. . FIG. 13.25. ###ESQUEMATIZAÇÃO DO PROCESSO DE NORMALIZAÇÃO DE TABELAS a uma BASE DE DADOS Modelo e MODELOS FIG.13.17. É com uma ####TABELAS EM AULAS É na o bom e o Então e. ###FORMA a Um ####FORMAM O E U C UM L BOM A e o o Com UM modelo, O se dá bom o bom. .A..D (2 fn FORMA (3fn Modelo do modelo. ## 189 Um d S e c de. ####ANOMALIAS D a Então BOM. Então e. o O e de A1 F Os e A bom e A d e é no o de CÃO de e b. e b de d cã A d A e c A1 b a o A1 e a C Modelo .bom e C E MODELOS e ## 190 As a Bom e C do modelo Não b bom. Na: B C A D Comunidade 268 e bom Na: . bom modelo. Os não bom. ## 191 ComBom o o B1C são ou mais, com a se . A1 o d A1 e c o bom modelo bom A1oB1C ## 192 Bom 1576 Com A1 Com um do a UM um modelo bom e bom COM . """"" Com bom Um para modelos BOM Com modelos. ## 13.4