UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE)

Save this PDF as:
 WORD  PNG  TXT  JPG

Tamanho: px
Começar a partir da página:

Download "UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE)"

Transcrição

1 UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE) COORDENAÇÃO GERAL DE EDUCAÇÃO A DISTÂNCIA (EAD/UFRPE) Banco de Dados Sandra de Albuquerque Siebra Volume 3 Recife, 2010

2 Universidade Federal Rural de Pernambuco Reitor: Prof. Valmar Corrêa de Andrade Vice-Reitor: Prof. Reginaldo Barros Pró-Reitor de Administração: Prof. Francisco Fernando Ramos Carvalho Pró-Reitor de Extensão: Prof. Paulo Donizeti Siepierski Pró-Reitor de Pesquisa e Pós-Graduação: Prof. Fernando José Freire Pró-Reitor de Planejamento: Prof. Rinaldo Luiz Caraciolo Ferreira Pró-Reitora de Ensino de Graduação: Profª. Maria José de Sena Coordenação Geral de Ensino a Distância: Profª Marizete Silva Santos Produção Gráfica e Editorial Capa e Editoração: Rafael Lira, Italo Amorim e Arlinda Torres Revisão Ortográfica: Elias Vieira Ilustrações: Noé Aprígio Coordenação de Produção: Marizete Silva Santos

3 Sumário Apresentação... 4 Conhecendo o Volume Capítulo 7 O Modelo Relacional... 7 O Modelo Relacional (MR)...7 Conceitos do Modelo Relacional...8 Regras de Integridade Fundamentais...14 As 12 Regras de Codd...18 Capítulo 8 Derivando o MR a partir do MER Algumas Informações Iniciais...25 Regras para Derivar o Modelo Relacional a partir do MER...26 Capítulo 9 Normalização de Dados Dependências Funcionais...41 Anomalias de Atualização...43 O que é Normalização?...45 Primeira Forma Normal (1FN)...47 Segunda Forma Normal...49 Terceira Forma Normal...52 Forma Normal de Boyce-Codd...55 Quarta Forma Normal...56 Quinta Forma Normal...58 Um Roteiro para a Normalização...60 Algumas Informações Adicionais...60 Considerações Finais Conheça a Autora... 69

4 Apresentação Caro(a) cursista, Seja bem-vindo(a) ao terceiro módulo do curso Banco de Dados! Neste terceiro módulo, vamos estudar o modelo relacional e todas as suas nuances. O modelo relacional é o resultado da modelagem lógica do Banco de Dados e é a etapa seguinte a modelagem conceitual. Dentro deste contexto, estudaremos como tranformar a modelagem conceitual em modelagem lógica, como otimizar o modelo criado através das regras de normalização e como fazer as checagens de integridade referencial. Bons estudos! Sandra de Albuquerque Siebra Autora 4

5 Conhecendo o Volume 3 Neste terceiro volume, você irá encontrar o Módulo 3 da disciplina de Banco de Dados. Para facilitar seus estudos, veja a organização deste segundo módulo. Módulo 3 Modelagem Lógica e Projeto de Banco de Dados Carga horária do Módulo 3: 15 h/aula Objetivo do Módulo 3:» Introduzir os principais conceitos e definições relacionados à modelagem lógica de dados.» Examinar os principais conceitos envolvidos no modelo relacional.» Estudar como derivar a modelagem lógica a partir da modelagem conceitual.» Estudar como otimizar a modelagem de dados através da normalização. Conteúdo Programático do Módulo 3:» O Modelo Relacional.» As 12 Regras de Codd.» Transformação do Modelo E-R para o Modelo Relacional.» Restrições de Integridade.» Dependências Funcionais.» Normalização de Dados. 5

6 Capítulo 7 O que vamos estudar neste capítulo? Neste capítulo, vamos estudar os seguintes temas:» O Modelo Relacional.» Restrições de Integridade.» As 12 Regras de Codd. Metas Após o estudo deste capítulo, esperamos que você consiga:» Identificar as particularidades e os componentes do Modelo Relacional.» Fazer a checagem de integridade do modelo.» Reconhecer as 12 regras de Codd. 6

7 Capítulo 7 O Modelo Relacional Vamos conversar sobre o assunto? No projeto de Banco de Dados, a modelagem lógica ou projeto lógico é a terceira etapa (vide Figura 1), antecedida pela análise de requisitos e pela modelagem conceitual. O produto dessa etapa é o modelo relacional ou esquema relacional e este é justamente o assunto desse capítulo! Esse modelo já é dependente do SGBD que for ser escolhido para a implementação do banco de dados. Logo, atente para o fato de que esse é o momento dessa decisão ser tomada. Neste capítulo, vamos falar sobre o modelo relacional, que é um exemplo de modelo lógico de dados, e sobre os conceitos a ele relacionados. Figura 1 - Etapas do Projeto de Banco de Dados O Modelo Relacional (MR) Vamos relembrar... o que é o modelo lógico? É um modelo que vai especificar a representação/declaração dos dados de acordo com o SGBD escolhido, definindo assim a estrutura de registros do BD (onde cada registro define número fixo de campos (atributos) e cada campo possui tamanho fixo). Um exemplo de modelo lógico é o modelo relacional (MR). Os SGBDs que utilizam o MR são denominados SGBDs Relacionais e, nesta disciplina, trataremos do projeto lógico apenas desse tipo de SGBD. 7

8 O Modelo Relacional foi introduzido por Ted Codd, da IBM Research, em 1970, em um artigo clássico (Codd, 1970) que imediatamente atraiu a atenção em virtude de sua simplicidade e base matemática. O modelo usa o conceito de uma relação matemática algo como uma tabela de valores como seu bloco de construção básica e tem sua base teórica na teoria dos conjuntos. As primeiras implementações comerciais do modelo relacional tornaram-se disponíveis no início da década de 80, antes disso, eram utilizados os modelos de redes e hierárquico (sobre os quais estudamos no Volume 1, capítulo 1). Comentário 1 A palavra relação é utilizada no sentido de lista ou rol de informações e não no sentido de associação ou relacionamento. O modelo relacional tem como objetivos: prover esquemas de fácil utilização; melhorar a independência lógica e física de dados; prover os usuários com linguagens de manipulação de BD de alto nível, permitindo o seu uso por usuários não experientes; otimizar o acesso aos BDs e melhorar a integridade e segurança dos dados. O MR representa os dados do BD como relações 1 (tabelas) de nomes únicos. O conceito de tabelas está intimamente ligado ao conceito de uma relação matemática de onde se origina o nome deste modelo. Vamos apresentar, na seção a seguir, cada um dos conceitos relevantes dentro do contexto do modelo relacional. Conceitos do Modelo Relacional Em um ambiente de banco de dados relacional utilizamos alguns conceitos muito importantes para a correta implantação e operação de qualquer sistema de banco de dados. Por exemplo, na terminologia do modelo relacional, cada tabela é chamada relação e vai possuir um nome único que a identifica, cada linha da tabela é chamada tupla, cada cabeçalho de coluna é conhecido como atributo (vide Figura 2). Figura 2 - Exemplos de Terminologias do Modelo Relacional Alguns desses novos termos originam-se diretamente da Teoria de Conjuntos, outros são decorrentes da utilização de elos lógicos para implementar os relacionamentos entre os dados armazenados no banco de dados. A seguir, cada um dos conceitos fundamentais do modelo relacional será descrito. Tabela ou Relação No modelo relacional, a estrutura que armazena os dados referentes a cada uma das ocorrências de uma entidade ou relacionamento com atributos do MER é chamada de tabela ou relação. Uma tabela é uma representação bi-dimensional de dados composta de linhas e colunas. Por exemplo, a tabela de empregados de uma empresa (vide Tabela 1) onde 8

9 poderiam ser armazenados dados como o CPF, o nome e o telefone de cada empregado. A tabela como um todo representaria os empregados da empresa. Cada coluna representaria um atributo (ex: a primeira coluna da Tabela 1 é o CPF ). E cada linha da tabela representa os dados de um empregado. Por exemplo, a primeira linha da Tabela 1 se refere à empregada de CPF número , de nome Ana Marques e cujo telefone é Tabela 1 - Tabela ou Relação Empregado CPF Nome Telefone Ana Marques João Pontes Marcos Alves Tânia Gomes Matematicamente, define-se uma relação como um subconjunto de um produto cartesiano de uma lista de domínios 2. Assim, suponha que D1 denote o domínio do atributo A1, D2 denote o domínio do atributo A2 e Dn denote o domínio do atributo N da tabela T1. Qualquer linha da tabela que possui estes atributos é denotada pela tupla 3 (d1,d2,...,dn) em que d1, d2 e dn têm como valores possíveis (domínios), respectivamente D1, D2 e Dn. Em geral, uma instância de T1 é um subconjunto de D1 X D2 X... X Dn. O conjunto de atributos de uma relação é chamado de esquema da relação. O esquema de uma relação é denotado por : R[A1 D1,..., An Dn] onde: R é o nome da relação; A1,..., An é a lista de atributos da relação R e D1,..., Dn são os domínios de cada um dos atributos da relação R. Frequentemente, é utilizada uma notação simplificada em que é omitida a definição do domínio de cada atributo da relação: R[A1,..., An]. Por exemplo, o esquema da relação representada na Tabela 1 seria: Empregado[CPF char 4 (11), Nome char(50), Telefone char(9)] ou, na notação simplificada, teríamos Empregado[CPF, Nome, Telefone]. Na criação dos esquemas das relações o nome das relações ou tabelas devem ser únicos no banco de dados, devem ser escritos no singular e, de preferência, devem ser nomes curtos. Se for usado um nome composto, este deve ser separado por um underline (_), por exemplo Pessoa_Fisica ou Pessoa_Juridica. O atributo identificador da relação é apresentado sublinhado (esse atributo identificador dará origem à chave primária da relação, como veremos mais a frente). Assim, se CPF fosse o atributo identificador teríamos: Empregado[CPF, Nome, Telefone]. O grau de uma relação é o número de atributos que a compõe. Por exemplo, o grau da relação Empregado[CPF, Nome, Telefone] é três, porque essa relação possui 3 atributos. Uma particularidade referente à definição de relação é que, nesta definição, não existe qualquer tipo de ordenação ou de definição de ordenação. Assim, por exemplo, as duas relações representadas pelas Tabelas 1 e 2 são consideradas idênticas. Afinal, o que mudou de uma tabela para outra foi apenas a ordem em que os valores de preenchimento da tabela aparecem. Comentário 2 Um domínio contém os valores possíveis para um determinado atributo da relação. Comentário 3 Uma tupla é uma ocorrência particular de um elemento da tabela. Falaremos sobre esse conceito, em detalheas, mais a frente. Comentário 4 O tipo char equivale ao tipo string das linguagens de programação, onde você pode digitar letras, números e símbolos. Quando você define um tipo char, você tem de especificar o tamanho do que preencherá o mesmo. Esse tipo pode variar de nome de SGBD para SGBD mas sempre vai ter um correspondente. 9

10 Tabela 2 - Tabela ou Relação Empregado CPF Nome Telefone Marcos Alves Tânia Gomes João Pontes Ana Marques Linha (Tupla) Uma ocorrência em particular de dados em uma tabela ocupa uma linha dessa tabela. Por exemplo, na Tabela 3, os dados de cada um dos empregados que a compõe ocupam uma linha diferente da tabela. Como existem 4 empregados, a Tabela 3 possui 4 linhas (ou tuplas ou registros). O número de linhas ou tuplas de uma relação é chamado de cardinalidade da relação. Logo, a cardinalidade da relação expressa na Tabela 3 é quatro. Cada linha da tabela deve ser única e deve possuir um atributo identificador. No caso da Tabela 3, esse identificador é o CPF do empregado. O atributo identificador, no modelo relacional, passa a ser chamado de chave primária (PK) - detalharemos melhor esse ponto mais a frente. Tabela 3 - Exemplos de Atributos e Tuplas Outra definição que pode ser dada para linha ou tupla é: um conjunto de pares (<atributo>,<valor>), em que cada par fornece o valor do mapeamento de um atributo Ai para um valor Vi, tal que cada valor Vi seja um elemento do domínio Di ou um valor nulo. Algumas regras para tuplas são: em uma tabela ou relação não devem existir tuplas ou linhas duplicadas. As linhas de uma tabela não seguem uma ordem específica. Dessa forma, as tuplas ou linhas abaixo seriam idênticas: T = <(CPF, ), (Nome, Ana Marques), (Telefone, )> e T = <(Telefone, ), (CPF, ), (Nome, Ana Marques)> Coluna (Atributo) Cada tipo de informação armazenada em uma tabela é uma coluna. Ou seja, cada 10

11 atributo que caracteriza a relação é expresso em uma coluna. Toda coluna de uma tabela deve possuir um nome pelo qual será referenciada sempre que necessário. Na verdade, ao criarmos uma tabela definimos, para cada uma de suas colunas, o seu nome (nome do atributo) e também o seu tipo (numérico, alfabético, data, etc). Por exemplo, CPF, Nome e Telefone são atributos (colunas ou campos) da Tabela Empregado, expressos na Tabela 3. Um nome de atributo deve ser único em uma tabela e deve expressar o tipo de informação que ele representa. E o valor de um atributo não deve poder ser decomposto em mais de uma coluna. Domínio do Atributo Domínio de um atributo é a faixa de valores que esse atributo pode conter. Em outras palavras, é o conjunto de valores que um determinado atributo pode assumir. Por exemplo, para o atributo CPF da Tabela 3, o domínio seria o conjunto dos números naturais. Em outras tabelas quaisquer, por exemplo, o domíno do atributo dia do mês seria o conjunto dos números entre 1 e 31. O atributo sexo teria como domínio os mnemônicos M (para masculino) ou F (para feminino) e assim por diante. Sempre que identificamos um atributo de uma tabela, temos também uma ideia de qual o tipo de informação que ele poderá vir a conter. Chaves Uma chave 5 é um atributo (ou conjunto de atributos) que identifica univocamente cada entrada de uma relação. Ou seja, por meio de chaves podemos diferenciar as diversas tuplas pertencentes a uma relação. Como consequência dessa definição, temos que os atributos chaves não podem apresentar valores duplicados, nem podem ser nulos. NULO - Não devemos confundir o conceito de nulo com espaços em branco ou o número zero, por exemplo, que são valores conhecidos. Nulo é a ausência de informação. Uma coluna de preenchimento obrigatório numa tabela deve possuir todos os seus valores nãonulos. Se, por exemplo, uma linha da tabela Empregado contiver um nulo na coluna Telefone, significa que o telefone do empregado correspondente àquela linha é desconhecido. Assim, ou o telefone não foi informado por algum motivo ou o empregado não possui telefone, de qualquer forma, a informação está ausente na tabela. Uma definição mais formal para chave seria: seja R um esquema de relação. Se dissermos que um subconjunto K de atributos de R é uma superchave 6 para R, estaremos considerando restrições para as relações r(r), nas quais não existem duas tuplas distintas com mesmos valores em todos os atributos de K. Isto é, se as tuplas t1 e t2 fazem parte da relação r e t1 <> t2, então t1[k] <> t2[k]. Quando há a possibilidade de mais de um atributo (isoladamente) poder ser chave em uma relação, dizemos que esses atributos são chaves candidatas. Por exemplo, na Tabela 4, CPF e Nome poderiam ser chaves candidatas, porque poderiam ser atributos usados para localizar uma entrada na tabela. Comentário 5 O conceito de chave está diretamente ligado ao de identificador da entidade ou relacionamento que foi estudado no volume anterior, quando foram detalhados os componentes do MER. Comentário 6 Superchave é o conjunto de um ou mais atributos que nos permitem identificar de maneira unívoca uma tupla de uma relação. 11

12 Tabela 4 - Tabela ou Relação Empregado CPF (PK) Nome Telefone Marcos Alves Tânia Gomes João Pontes Ana Marques Um dos princípios do modelo relacional diz que uma linha de uma tabela deve sempre poder ser referenciada de forma única. Por isso, entre as chaves candidatas, uma delas deve ser eleita para ser a principal, a chave primária da tabela (Primary Key ou PK), aquela que realmente identifica univocamente cada tupla da tabela. No caso, para a Tabela 4, a melhor escolha para chave primária seria o atributo CPF, já que essa informação não se repetiria, de forma alguma, em dois empregados distintos da tabela. A escolha da chave primária (PK) da tabela é influenciada pelas necessidades do domíno do mundo real que está sendo modelado. Chaves primárias são geralmente indicadas na tabela pela sigla PK (Primary Key) e podem também ser sublinhadas (vide Tabela 4). As outras chaves candidatas que não forem escolhidas para chave primária, são chamadas de chaves secundárias. Por exemplo, na Tabela 4, o atributo Nome seria uma chave secundária. Muitas vezes, uma tabela não possui, entre seus atributos, um que por si só seja suficiente para identificar univocamente uma ocorrência. Nesses casos deve sempre ser possível que a combinação de dois ou mais atributos tenha a capacidade de se constituir numa chave primária. Chamamos a essas chaves primárias formadas pela combinação de vários atributos de chaves primárias compostas. Ou seja, uma chave primária composta é uma chave primária que é formada por mais de um atributo ou coluna. Geralmente, uma tabela que represente um relacionamento entre outras duas tabelas (originada de um relacionamento do MER) irá possuir chaves primárias compostas. Por exemplo, a tabela Alocação (vide Tabela 5), terá como chaves primárias os atributos CPF e Cod_Projeto. Isso, porque para descobrir qual a função de um empregado em um projeto, precisamos dessas duas informações. Nenhum dos atributos isoladamente poderia fornecer essa informação. Tabela 5 - Tabela ou Relação Alocação CPF (PK) Cod_projeto (PK) Função Analista Consultor Suporte Programador 12

13 Tabela 6 - Tabela ou Relação Empregado CPF (PK) Nome Telefone Marcos Alves Tânia Gomes João Pontes Ana Marques Tabela 7 - Tabela ou Relação Projeto Cod_projeto (PK) Nome Projeto 001 SOFTHOUSE 002 GEOPROC 003 LINUX WORLD Uma tabela pode incluir entre seus atributos a chave primária de outra tabela. Essa chave é chamada chave estrangeira. Ou seja, uma chave estrangeira é uma coluna (ou combinação de colunas) que indica um valor que deve existir como chave primária em uma outra tabela (chamada de Tabela Pai). Por exemplo, na tabela Alocação (vide Tabela 5), as colunas CPF e Cod_Projeto são chaves estrangeiras, porque elas são chave primária, respectivamente, das tabelas Empregado (vide Tabela 6) e Projeto (vide Tabela 7). Vamos definir novamente com outras palavras: uma chave estrangeira de uma relação R1 é um atributo (ou conjunto de atributos) que referencia a chave primária de uma outra relação R2. Dessa forma, para qualquer tupla de R1, o valor da chave estrangeira deve ser igual ao valor da chave primária de alguma tupla da relação R2 referenciada, ou deve ser o valor nulo (se a chave estrangeira não fizer parte da chave primária da relação R1). Com isso queremos dizer que o atributo que é chave estrangeira em uma relação R1, pode ou não fazer parte da chave primária de R1. No exemplo de chave estrangeira dado anteriormente, as chaves estrangeiras CPF e Cod_Projeto fazem parte da chave primária da tabela Alocação (vide Tabela 5). Porém, a chave estrangeira pode não fazer parte da chave primária. Observe a tabela Funcionário (vide Tabela 8). Ela possui um campo Cod_Depto que é chave primária da tabela Departamento (vide Tabela 9). Logo, na tabela Funcionário, o atributo Cod_Depto é uma chave estrangeira. Chaves estrangeiras são indicadas pela sigla FK (Foreign Key). Tabela 8 - Tabela ou Relação Funcionário CPF (PK) Nome Cod_Depto (FK) Marcos Alves Tânia Gomes João Pontes Ana Marques 22 13

14 Tabela 9 - Tabela ou Relação Departamento Cod_Depto (PK) Nome 11 Vendas 22 Financeiro Uma chave estrangeira formada por mais de uma coluna é chamada de chave estrangeira composta. No modelo relacional os relacionamentos representados no MER passam a ser representados através de chaves estrangeiras. Ou seja, as chaves estrangeiras tornam possível a associação lógica entre tabelas distintas. Isso ficará mais claro no próximo capítulo quando forem apresentadas as regras de derivação do MR a partir do MER. Regras de Integridade Fundamentais O modelo relacional, ao definir conceitos como Tabela, Tupla, Atributo, Nulo, Domínio, Chave Primária e Chave Estrangeira deixa implícitas algumas regras fundamentais para a manutenção da consistência do banco de dados. Elas são chamadas de Regras de Integridade e tratam dos cuidados que analistas, projetistas e programadores devem observar ao implementar as rotinas de Inclusão, Alteração e Exclusão de dados nas bases de dados. Na prática, as restrições de integridade fornecem meios para assegurar que mudanças feitas no banco de dados não resultem na perda da consistência sobre estes dados. Vamos ver agora dois dos principais tipos de integridade a serem mantidas em um banco de dados adequadamente projetado: a Integridade de Entidade e a Integridade Referencial. Posteriormente, discutiremos regras de integridade complementares e regras de integridade semântica. Integridade de Entidade (ou de Identidade ou Existencial) Refere-se às chaves primárias e procura garantir que toda e qualquer linha de uma tabela deve poder ser acessada com base apenas no conteúdo de sua chave primária. Para isso, algumas regras devem ser observadas:» Toda tupla tem um conjunto de atributos que a identifica de maneira única na relação (Integridade de Chave).» Nenhum atributo que faça parte de uma chave primária pode ter valor nulo (eles devem ser NN = not null).» Não se deve permitir que em uma mesma tabela existam duas ocorrências (tuplas) com chaves primárias iguais. Ou seja, os atributos que são chave primária devem ser únicos (ND = No Duplicate ou Unique). Isso significa que os conteúdos de todos os atributos que constituem uma chave primária devem ser conhecidos e únicos. Um conteúdo nulo representa uma informação desconhecida ou, em outras palavras, a ausência da informação, o que não pode ser permitido em qualquer elemento de uma chave primária. Algumas recomendações para se alcançar a integridade de entidade são: 14

15 » Selecione chaves primárias que realmente tenham preenchimento único no domínio do problema.» Se possível, prefira chaves primárias simples e numéricas.» Se não houver nenhuma coluna que possa ser uma chave candidata, utilize chaves primárias sequenciais, geralmente, atribuídas pelo sistema. Integridade Referencial Diz respeito às chaves estrangeiras e visa manter a integridade dos relacionamentos previstos no banco de dados. Ou seja, a integridade referencial cuida para que uma relação possa ter um conjunto de atributos que contém valores com mesmo domínio de um conjunto de atributos que forma a chave primária de outra relação. Este conjunto é chamado chave estrangeira. Na definição dos cuidados referentes a esse tipo de integridade, utilizaremos dois conceitos:» Tabela-Pai (Parent Table): é aquela onde o atributo de relacionamento desempenha o papel de chave primária.» Tabela-Filho (Dependent Table): tabela onde o atributo de relacionamento desempenha o papel de chave estrangeira. Para manter a integridade referencial, a regra básica é: o conteúdo de uma chave estrangeira deve, necessariamente, ser igual ao de uma ocorrência da Tabela-Pai ou então ser nulo. Vale ressaltar que o valor da chave estrangeira só poderá ser nulo na Tabela-Filho, se o atributo que for chave estrangeira não fizer parte da chave primária da Tabela-Filho. Por exemplo, na última tupla da tabela Funcionário (vide Tabela 10), temos que o Cod_Depto é NULL. Isso é possível apenas porque o atributo Cod_Depto não faz parte da chave primária da tabela Funcionário. E deve significar que, por enquanto, a funcionária Ana Marques não foi alocada em nenhum departamento (vamos supor que ela acabou de ser contratada). Já todas as outras tuplas da tabela Funcionário possuem o Cod_Depto preenchido e, para que a integridade referencial seja mantida, como esse atributo é chave estrangeira, ele deve existir como chave primária em alguma outra tabela. No caso, na tabela Departamento (vide Tabela 9). Nesse exemplo fornecido, a tabela Funcionário é a Tabela-Filho e a tabela Departamento é a Tabela-Pai. Tabela 10 - Tabela ou Relação Funcionário CPF (PK) Nome Cod_Depto (FK) Marcos Alves Tânia Gomes João Pontes Ana Marques NULL 15

16 Observação Uma chave estrangeira pode referenciar-se a um atributo da sua própria tabela (caso que ocorrerá com os auto-relacionamentos do MER). Por exemplo, a tabela Funcionário (vide Tabela 11) poderia ter, para cada funcionário, quem é o seu supervisor direto. Assim, o campo CPF_Supervisor, que é considerado chave estrangeira, é a chave primária da própria tabela Funcionário e não de outra tabela qualquer. Tabela 11 - Tabela ou Relação Funcionário CPF (PK) Nome CPF_Supervisor (FK) Marcos Alves Tânia Gomes João Pontes NULL As consequências da Integridade Referencial refletem-se nas consistências necessárias ao se proceder às operações de Inclusão, Alteração e Exclusão de dados nas Tabelas Pai e Filho. Veja as regras no Quadro 1. 16

17 Quadro 1 - Regras de Inclusão, Alteração e Exclusão para manter a Integridade Referencial Operação Tabela_Pai Tabela-Filho Inclusão A inclusão de dados na tabela-pai não tem nenhuma implicação ou problema. A inclusão de dados na Tabela- Filho deve atentar para o fato de que não será possível incluir uma nova tupla se o valor do campo que for chave estrangeira já não estiver cadastrado na Tabela-Pai. Se a alteração envolver o valor da chave primária, deve-se utilizar um dos seguintes critérios: Alteração» A chave não deve ser alterada se estiver sendo utilizada em alguma tabela-filho.» A chave deve ser alterada e deve-se colocar NULL nas chaves estrangeiras presentes na(s) Tabela(s)-Filho (contanto que o valor em questão não faça parte da chave primária da(s) Tabela(s)-Filho correspondente(s)). Se a alteração envolver o atributo que é chave estrangeira, a alteração só deve ser realizada usando valores que existam na tabela pai (podendo também usar o valor NULL, se essa chave estrangeira não fizer parte da chave primária da Tabela-Filho).» A chave deve ser alterada e o novo valor deve ser colocado no campo que é chave estrangeira em todas as tabelas-filho relacionadas. Para excluir uma tupla dessa tabela, deve-se utilizar um dos seguintes critérios: Exclusão» Não deletar, se a tupla estiver sendo utilizada em uma Tabela-Filho.» Deletar a tupla e colocar NULL nas chaves estrangeiras das Tabelas-Filhos afetadas (isso se o atributo envolvido não fizer parte da chaveprimária da Tabela-Filho). A exclusão de Dados na Tabela- Filho não tem nenhuma implicação ou problema.» Deletar e, também, eliminar todas as tuplas das Tabelas-Filho que façam uso do valor da tupla sendo eliminada. As restrições de integridade devem ser implementadas pelo SGBD. Muitos SGBD s implementam integridade de entidade, mas não implementam integridade referencial. Regras de Integridade Complementares Além das regras de integridade de entidade e referencial, um banco de dados relacional pode suportar um conjunto adicional de regras (ou restrições) cuja finalidade 17

18 é especificar aspectos próprios de cada coluna e respectivo domínio, complementando com isso a definição de suas características lógicas. As principais restrições de integridade complementares tratam da obrigatoriedade e unicidade de valores e sobre conjuntos de valores permitidos. Vamos às regras:» Obrigatoriedade - Indica se deve ou não ser permitida a existência de nulos em uma coluna (ou seja, se um atributo pode ou não ser nulo). Colunas que não aceitam nulos são de preenchimento obrigatório como, por exemplo, o nome de um funcionário na tabela de funcionários. Campos que não possuam obrigatoriedade de preenchimento são considerados campos opcionais. Por exemplo, o número do telefone poderia ser um campo opcional, dependendo do domínio, visto que ainda podem haver pessoas que não possuem número de telefone. A definição de se um campo será de preenchimento obrigatório ou não, vai depender muito do domínio do mundo real sendo modelado.» Unicidade - Indica se deve ser permitido ou não que uma coluna possua valores idênticos em duas ou mais linhas. Uma coluna que não pode possuir valores repetidos é uma coluna de valores únicos.» Verificação de Valores Específicos - Indica explicitamente qual o conjunto de valores permitidos para uma determinada coluna. Por exemplo, para a coluna Sexo de uma tabela Empregado só poderiam ser aceitos os valores M ou F. Qualquer outro valor deveria ser recusado. Restrições de Integridade Semântica São restrições especificadas e mantidas num banco de dados relacional pelo programa de aplicação e que são inerentes a aplicação sendo desenvolvida. Ou seja, são as regras de negócio do domínio do mundo real sendo implementado. Por exemplo, em um determinado sistema pode-se querer implementar a restrição que o salário de um empregado não pode ser maior do que o salário do seu supervisor direto ou que o número máximo de horas por semana que um empregado pode trabalhar em projetos é de 40 horas (suponha que a empresa não permite horas extras) ou, ainda, a data de entrega de um pedido não pode ser inferior à data em que o pedido foi realizado. Tais restrições, como dito, são específicas do domínio sendo implementado e necessitam ser programadas em cada aplicação que vá fazer uso do banco de dados. As 12 Regras de Codd Edgard F. Codd, em 1985, estabeleceu as 12 regras de Codd que determinam o quanto um banco de dados é relacional. Algumas vezes as regras se tornam uma barreira e nem todos os SGBDs relacionais fornecem suporte a elas. De qualquer forma, a título de conhecimento, vamos apresentá-las a seguir. Lembramos que nem todas as regras serão completamente compreendidas nesse momento, mas o serão até o final da disciplina. Regra 1 - Regra das informações em tabelas: As informações a serem armazenadas no banco de dados devem ser apresentadas como relações (tabelas formadas por linhas e colunas) e o vínculo de dados entre as tabelas deve ser estabelecido por meio de valores de campos comuns (chaves estrangeiras). Regra 2 - Regra de acesso garantido: Todo e qualquer valor atômico em um BD relacional possui a garantia de ser logicamente acessado pela combinação do nome da tabela, do valor da chave primária e do nome do campo/coluna que deseja acessar. Isso 18

19 porque, com o nome da tabela, se localiza a tabela desejada. Com o valor da chave primária a tupla desejada dentro da tabela é localizada. E com o nome do campo/coluna se acessa a parte desejada da tupla. Regra 3 - Regra de tratamento sistemático de valores nulos: Valores nulos devem ser suportados de forma sistemática e independente do tipo de dado para representar informações inexistentes e informações inaplicáveis. Deve-se sempre lembrar que valores nulos devem ter um tratamento diferente de valores em branco. Regra 4 - Regra do catálogo relacional ativo: Toda a estrutura do banco de dados (domínios, campos, tabelas, regras de integridade, índices, etc) deve estar disponível em tabelas (também referenciadas como catálogo). Sua manipulação é possível por meio de linguagens específicas (por exemplo, SQL). Essas tabelas são, geralmente, manipuladas pelo próprio sistema no momento em que o usuário efetua alterações na estrutura do banco de dados (por exemplo, a inclusão de um novo atributo em uma tabela). Regra 5 - Regras de atualização de alto-nível: Essa regra diz que o usuário deve ter capacidade de manipular as informações do banco de dados em grupos de registros, ou seja, ser capaz de inserir, alterar e excluir vários registros ao mesmo tempo 7. Regra 6 - Regra de sub-linguagem de dados abrangente: Pelo menos uma linguagem, com sintaxe bem definida, deve ser suportada, para que o usuário possa manipular a estrutura do banco de dados (como criação e alteração de tabelas), assim como extrair, inserir, atualizar ou excluir dados, definir restrições de integridade e de acesso e controle de transações (commit e rollback 8, por exemplo). Deve ser possível ainda a manipulação dos dados por meio de programas aplicativos. Regra 7 - Regra de independência física: Quando for necessária alguma modificação na forma como os dados estão armazenados fisicamente, nenhuma alteração deve ser necessária nas aplicações que fazem uso do banco de dados (isolamento), assim como devem permanecer inalterados os mecanismos de consulta e manipulação de dados utilizados pelos usuários finais. Regra 8 - Regra de independência lógica: Qualquer alteração efetuada na estrutura do banco de dados como inclusão ou exclusão de campos de uma tabela ou alteração no relacionamento entre tabelas não deve afetar o aplicativo utilizado ou ter um baixo impacto sobre o mesmo. Da mesma forma, o aplicativo somente deve manipular visões 9 dessas tabelas. Regra 9 - Regra de atualização de visões: Uma vez que as visões dos dados de uma ou mais tabelas são, teoricamente, suscetíveis a atualizações, então um aplicativo que faz uso desses dados deve ser capaz de efetuar alterações, exclusões e inclusões neles. Essas atualizações, no entanto, devem ser repassadas automaticamente às tabelas originais. Ou seja, a atualização em uma visão deve refletir na atualização das tabelas representadas por essa visão. Regra 10 - Regra de independência de integridade: As várias formas de integridade de banco de dados (integridade de entidade, integridade referencial e restrições de integridade complementares) precisam ser estabelecidas dentro do catálogo do sistema ou dicionário de dados e serem totalmente independentes da lógica dos aplicativos. Assim, os aplicativos não devem ser afetados quando ocorrerem mudanças nas regras de restrições de integridade. Comentário 7 Veremos como fazer isso no último volume desta disicplina, quando estivermos estudando a linguagem SQL. Comentário 8 Commit serve para confirmar as operações realizadas no banco de dados. Rollback serve para desfazer uma operação que ainda não tenha sido confirmada. Comentário 9 Visão: é uma relação virtual que não faz parte do esquema conceitual do BD, mas que é visível a um grupo de usuários. Em outras palavras, uma visão é uma tabela virtual que é definida a partir de outras tabelas, contendo sempre os dados atualizados. Regra 11 - Regra de independência de distribuição: Alguns SGBDs, notadamente os que seguem o padrão SQL, podem ser distribuídos em diversas plataformas/equipamentos que se encontrem interligados em rede. Essa capacidade de distribuição não pode afetar a funcionalidade do sistema e dos aplicativos que fazem uso do banco de dados. Em resumo, 19

20 as aplicações não são logicamente afetadas quando ocorrem mudanças geográficas dos dados (caso dos BDs distribuídos). Regra 12 - Regra não-subversiva: O sistema deve ser capaz de impedir qualquer usuário ou programador de transgredir os mecanismos de segurança, regras de integridade do banco de dados e restrições, utilizando algum recurso de linguagem de baixo nível que eventualmente possam ser oferecidos pelo próprio sistema. Conheça Mais Neste capítulo foram vistos conceitos básicos do modelo relacional. Para obter mais informações ou materiais diversificados para o que foi visto aqui, você pode proceder a uma pesquisa usando o Google (www.google.com.br) com as palavras chaves Modelagem Lógica + Banco de Dados ou Modelo Relacional ou ainda Esquema Relacional. Você vai ver que virá muito material. Entre eles: apostilas, notas de aula, reportagens, etc. Adicionalmente, você pode consultar qualquer livro sobre banco de dados, pois qualquer um deles terá um ou mais capítulos voltados para a explicação do modelo relacional. Entre os livros que podemos indicar estão: HEUSER, CARLOS ALBERTO. Projeto De Banco De Dados Série Livros Didáticos, V.4. Bookman Companhia Ed., 6ª Edição SILBERSCHATZ, Abraham; KORTH, Henry F; SUDARSHAN, S. Sistema de banco de dados. Traduzido por Daniel Vieira. Rio de Janeiro: Elsevier;Campus, ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4a. ed. São Paulo: Pearson Education do Brasil, DATE, C. J. Introdução a sistemas de bancos de dados. Rio de Janeiro: Campus, ALVES, W.P. Fundamentos de Bancos de Dados. Editora Érica, Você Sabia? A linguagem padrão dos Bancos de Dados Relacionais é a Structured Query Language, ou simplesmente SQL, como é mais conhecida. Ela será assunto do próximo volume (Volume 4) da disciplina. Aprenda Praticando Vamos dar uma olhada novamente em questões de concurso? NCE-UFRJ TRE-RJ - Analista Judiciário - Especialidade - Análise de Sistemas - Desenvolvimento 1) Sobre os conceitos de domínio, atributo e relacionamento, é correto afirmar que: a) um domínio é definido pelo conjunto dos atributos pertencentes a um relacionamento; 20

21 b) domínio e atributo representam um único conceito semântico; c) um atributo é considerado identificador se pertencer ao domínio que define um relacionamento; d) todos os atributos de uma relação devem pertencer a um mesmo domínio; e) domínio são os valores possíveis que um atributo pode assumir. 2) A cardinalidade de uma relação é caracterizada por: a) Número de atributos dessa relação; b) Número de campos dessa relação; c) Quantidade de chaves estrangeiras da relação; d) Número de tuplas de uma relação; e) Nenhuma das respostas anteriores. 3) Uma chave estrangeira: a) Pode conter valores que não existem na Tabela-Pai (tabela referenciada); b) Pode não pertencer à chave primária; c) Tem de pertencer, obrigatoriamente, à chave primária; d) Podem sempre assumir o valor nulo; e) Nenhuma das respostas anteriores. Fundação Getúlio Vargas ) No contexto de Banco de Dados, um conceito assegura que um valor que aparece em uma tabela para um determinado conjunto de atributos apareça em outro conjunto de atributos de outra tabela. Por exemplo, se cristalina é o nome de uma agência que aparece em uma tupla da tabela conta, então deve existir uma tupla cristalina na tabela agencia. Esse conceito é definido como um sistema de regras, utilizado para garantir que os relacionamentos entre tuplas de tabelas relacionadas sejam válidas e que não exclui ou altera, acidentalmente, dados relacionados. Tratase do seguinte conceito: a) Integridade Funcional; b) Dependência Funcional; c) Integridade Relacional; d) Dependência Referencial; e) Integridade Referencial. (Técnico de Tecnologia da Informação/UFT/FCC/2005) 5) Os dois principais tipos de integridade a serem mantidos em um banco de dados relacional adequadamente projetado são: a) Integridade Existencial e Integridade Permanente; b) Integridade de Entidade e Integridade de Relacionamento; c) Integridade de Entidade e Integridade Referencial; d) Integridade Permanente e Integridade Referencial; e) Integridade Existencial e Integridade de Entidade. (Administrador/PM SANTOS/FCC/2005) 21

22 6) Um tipo de dado específico, como por exemplo Nome do Funcionário, é armazenado numa localização da estrutura do banco de dados denominada. a) Tabela; b) Linha; c) Planilha; d) Coluna; e) Registro. Respostas: 1) E O domínio de um atributo são os valores que ele pode assumir. Ou seja, é o tipo deste atributo. Por exemplo, o atributo dia do mês tem como domínio os valores naturais entre 1 e 31. 2) C A cardinalidade de uma relação é o número de linhas ou tuplas dessa relação. Assim, uma relação com quatro tuplas, tem cardinalidade 4. 3) B Uma chave estrangeira pode não pertencer à chave primária, não pode conter valores que não existam na tabela-pai e só podem assumir valor nulo se não pertencer à chave primária da tabela onde é chave estrangeira. 4) E Integridade Referencial. Ela checa todas as validações necessárias referentes ao uso de chaves estrangeiras. 5) C os dois principais tipos de integridade que podem ser verificados em um BD relacional são a integridade de entidade (que se referem às checagens da chave primária) e a integriadade referencial (que se refere às checagens da chave estrangeira). 6) D Nome do funcionário é tipicamente um atributo e um atributo é representado no BD relacional por uma coluna. Atividades e Orientações de Estudo Agora vamos exercitar o que foi estudado neste capítulo. Assim sendo, faça as atividades sugeridas a seguir. Lembre que exercitar vai ajudá-lo(a) a fixar melhor o conteúdo estudado. E o conteúdo desse capítulo é fundamental para o capítulo seguinte, onde vamos aprender a construir o Modelo Relacional. Mãos à obra! Atividades Práticas: Responda as questões a seguir em um documento de texto (doc) e poste as respostas no ambiente virtual, no local indicado. Esse trabalho deve ser feito individualmente. (Exercícios adaptados do livro de Carlos Heuser (1998) - capítulo 4). Exercício 1: Abaixo aparecem diversos esquemas de relação que compõem um banco de dados relacional. Identifique nestes esquemas, da maneira apropriada, as chaves primárias e chaves estrangeiras: Aluno (CodigoAluno,Nome,CodigoCurso) Curso(CodigoCurso,Nome) 22

23 Disciplina(CodigoDisciplina,Nome,Creditos,CodigoDepartamento) Curriculo(CodigoCurso,CodigoDisciplina,Obrigatória-Opcional) Conceito(CodigoAluno,CodigoDisciplina,Ano-Semestre,Conceito) Departamento(CodigoDepartamento,Nome) Exercício 2: Considere o esquema das relações de um BD relacional a seguir: Paciente(CodigoConvenio (FK), NumeroPaciente, Nome) Convenio(CodigoConvenio, Nome) Medico(CRM, Nome, Especialização) Consulta(CodigoConvenio (FK), NumeroPaciente (FK), CRM(FK), Data-Hora) A partir desse esquema, explique que verificações/checagens deveriam ser feitas pelo SGBD para garantir integridade referencial nas seguintes situações: a) Uma linha é incluída na tabela Consulta. b) Uma linha é excluída da tabela Paciente. Vamos Revisar? Você estudou, neste capítulo, os conceitos básicos referentes ao modelo relacional. Entre eles, os conceitos de tabela ou relação, tuplas ou linhas, atributos ou colunas e chaves (chave candidata, primária, secundária e estrangeira). Esses conceitos serão todos utilizados no próximo capítulo onde você aprenderá a derivar o modelo relacional a partir do modelo entidade-relacionamento. Adicionalmente, foram vistos também neste capítulo os principais tipos de integridade (de entidade e referencial), além de integridades complementares e integridade semântica. 23

24 Capítulo 8 O que vamos estudar neste capítulo? Neste capítulo, vamos estudar os seguintes temas:» Como derivar o MR a partir do MER. Metas Após o estudo deste capítulo, esperamos que você consiga:» Derivar o MR a partir do MER.» Verificar a corretude do modelo derivado. 24

25 Capítulo 8 Derivando o MR a partir do MER Vamos conversar sobre o assunto? Vimos no capítulo anterior os conceitos básicos do modelo relacional. Porém, ainda não vimos como gerar o modelo relacional, que faz parte da modelagem lógica do banco de dados, que é a terceira etapa do projeto de banco de dados como um todo. A melhor maneira de produzir o modelo relacional é derivá-lo a partir do modelo entidaderelacionamento. Para fazer isso, existem algumas regras. São justamente essas regras que discutiremos neste capítulo. Neste capítulo, você vai aprender como derivar o MR a partir do MER, para isso, todas as instruções de como fazer isso serão dadas. Vamos lá? Algumas Informações Iniciais A terceira fase do projeto de banco de dados é o projeto lógico que objetiva mapear o modelo de dados conceitual para o modelo de dados relacional. Essa fase dá origem ao esquema lógico representado pelo modelo relacional que já é um modelo que depende do SGBD e será usado para implementar o banco de dados. É comum, em projetos de banco de dados, se realizar a modelagem dos dados através de um modelo de dados de alto-nível. O modelo de dados de alto-nível normalmente adotado é o Modelo Entidade-Relacionamento (MER) e o esquema das visões e de toda a base de dados são especificados em diagramas entidade-relacionamento (DER). O passo seguinte à modelagem dos dados conceitual é o mapeamento do diagrama da base de dados global para um modelo de dados de implementação. Existem três tipos de modelos de dados de implementação: hierárquico, rede e relacional. Para cada um desses modelos, podem-se definir estratégias de tradução a partir do DER. A estratégia de tradução, ou de mapeamento, que trataremos neste capítulo e nesta disciplina será apenas para o modelo de dados relacional. O Modelo Relacional é a representação do modelo lógico do projeto de banco de dados, sendo que a forma de representação dos conceitos necessários ao projeto deve passar a ser mais detalhada e se aproximar um pouco mais da representação física. Dessa forma, várias mudanças devem ser realizadas no DER gerado na fase de modelagem conceitual, como, por exemplo: entidades passam a ser representadas por relações ou tabelas. Atributos passam a ser representados em colunas. O atributo identificador passa a ser a chave primária (PK) da tabela. Os relacionamentos e as dependências passam a ser representados por chaves estrangeiras (FK) e assim por diante. Na Figura 3, pode ser visto um exemplo do resultado da transformação de um MER em MR. Cada etapa desse mapeamento será estudada na seção a seguir. 25

26 Figura 3 - Passagem do MER para o MR Regras para Derivar o Modelo Relacional a partir do MER Agora, iremos estudar cada uma das etapas de derivação do MR a partir do MER.» Mapeamento de Entidades Fortes Cada conjunto de entidades fortes é mapeado como uma relação que envolve todos os atributos da entidade correspondente do DER. Assim, para cada entidade regular E no DER, criar uma relação R que inclua todos os atributos simples de E. Se houver atributos compostos, inclua apenas os atributos simples que compõem o atributo composto (ou seja, decomponha o atributo composto). O(s) atributo(s) identificador(es) da entidade E deve(m) ser marcado(s) como chave primária da relação R. Por exemplo, suponha a entidade Aluno que possui dois atributos CPF e Nome, sendo o CPF o atributo identificador da entidade (vide Figura 4). No MR, seria criada uma relação ou tabela de nome Aluno, com duas colunas (atributos) CPF, que deveria ser marcado como chave primária (PK) e Nome. Como, anteriormente explicado, se houvesse atributos compostos, esses deveriam ser substituídos pelos atributos simples que o compõem (vide Figura 5). Assim, o atributo Endereço, que é composto pelos atributos Rua, Numero e Bairro, seria representado na relação apenas por estes últimos. Figura 4 - Exemplo de Mapeamento de Entidade Forte 26

27 Figura 5 - Exemplo de mapeamento de atributo composto» Mapeamento de Atributos Multivalorados Os atributos multivalorados vão se tornar relações cujas chaves primárias serão compostas pela chave da entidade possuidora do atributo mais o atributo multivalorado. Ou seja, para cada atributo A multivalorado, deve-se criar uma nova relação R que inclua o atributo multivalorado A e a chave-primária K da relação que representa o tipo de entidade ou o tipo de relacionamento que tem A como atributo. O detalhe é que a chave-primária da relação R será composta por K e pelo atributo A. Se o atributo multivalorado for composto, você deve seguir a instrução anteriormente dada de decompô-lo (usar os atributos simples que o compõem). Por exemplo, suponha a entidade Empregado (vide Figura 6). Ela possui os atributos CPF e Nome simples e o atributo Telefone que é multivalorado. Essa entidade seria mapeada para a relação Empregado (pela regra já descrita anteriormente) e o atributo mutivalorado Telefone daria origem a outra relação, que chamamos de Telefone_Empregado, contendo a chave primária da relação Empregado (que originou-se da entidade possuidora do atributo) e o atributo valorado, também fazendo parte da chave primária dessa nova relação. Figura 6 - Exemplo mapeamento de atributo multivalorado» Mapeamento de Entidades Fracas São mapeadas em uma relação formada por todos os atributos da entidade fraca mais os atributos que formam a chave primária da relação da qual a entidade fraca depende. O relacionamento não é mapeado. Assim, para cada tipo de entidade fraca EF do DER, criar uma relação R e incluir todos os atributos simples (ou os componentes simples de atributos compostos) de EF como atributos de R. Além disso, incluir como a chave-estrangeira de R a 27

28 chave-primária da relação que corresponde à entidade forte, da qual a entidade fraca depende. Logo, a chave primária da entidade fraca deverá ser formada pela chave primária da relação que representa a entidade forte da qual a entidade fraca depende e pelo atributo identificador da entidade fraca. Por exemplo, vide a Figura 7. A entidade forte Empregado foi mapeada para a relação Empregado, como explicado anteriormente. A entidade fraca Dependente deu origem a uma relação cuja chave primária é formada pela chave primária de empregado (CPF) e pelo identificador da própria entidade fraca (RG), além do atributo adicional Nome. Figura 7 - Exemplo de mapeamento de entidade fraca» Mapeamento de Relacionamentos Binários 1:1 Esse tipo de relacionamento não é mapeado em uma nova relação. Seus atributos são colocados em qualquer uma das relações que mapeiem as entidades envolvidas. A entidade escolhida para receber os atributos do relacionamento receberá, também, a chave primária da outra entidade envolvida. Assim, temos que, para cada tipo de relacionamento binário 1:1 R do DER, devem-se criar as relações E1 e E2 que correspondem aos tipos de entidade participantes do relacionamento R. Depois, deve-se escolher uma das relações, por exemplo, E1, para incluir nela, como chave-estrangeira, a chave-primária de E2. Devem-se incluir também em E1 todos os atributos simples (ou os componentes simples de atributos compostos) do tipo de relacionamento R. Por exemplo, suponha que Um empregado trabalha em uma empresa e uma empresa possui um único empregado (vide Figura 8). Esse é um relacionamento binário 1:1. Para mapeá-lo para o MR, devem-se criar duas relações Empregado e Empresa, conforme a maneira anteriormente explicada (mapeamento de entidade forte). Depois, seria escolhida uma das relações (suponha que escolhemos a relação Empregado) para receber os atributos do relacionamento (no caso, Dt_admissao) e a chave primária da relação que não for a escolhida (no caso, o atributo Codigo, que pertence à relação Empresa). Se a entidade escolhida fosse a relação Empresa (a escolha é sua) seria necessário colocar a chave primária da entidade Empregado na relação Empresa, assim como o atributo do relacionamento. Todas as duas abordagens seriam possíveis. 28

MODELO RELACIONAL - UFMA

MODELO RELACIONAL - UFMA MODELO RELACIONAL Universidade Federal do Maranhão - UFMA Departamento de Informática Projeto de Banco de Dados Profª.MSc Simara Rocha simararocha@gmail.com/simara@deinf.ufma.br www.deinf.ufma.br/~simara

Leia mais

Roteiro. Modelo de Dados Relacional. Processo de Projeto de Banco de Dados. BCC321 - Banco de Dados I. Ementa. Posicionamento.

Roteiro. Modelo de Dados Relacional. Processo de Projeto de Banco de Dados. BCC321 - Banco de Dados I. Ementa. Posicionamento. Roteiro Modelo de Dados Relacional Posicionamento Luiz Henrique de Campos Merschmann Departamento de Computação Universidade Federal de Ouro Preto luizhenrique@iceb.ufop.br www.decom.ufop.br/luiz Introdução

Leia mais

Modelo Relacional. Aécio Costa

Modelo Relacional. Aécio Costa Aécio Costa O Modelo de Dados Relacional foi introduzido por Codd (1970). Entre os modelos de dados de implementação, o modelo relacional é o mais simples, com estrutura de dados uniforme, e também o mais

Leia mais

Núcleo de Pós Graduação Pitágoras

Núcleo de Pós Graduação Pitágoras Núcleo de Pós Graduação Pitágoras Professor: Fernando Zaidan Disciplina: Modelagem e Projeto de Banco de Dados Especialização em Tecnologia da Informação - Ênfases Março- 2009 1 Material usado na montagem

Leia mais

Prof. Alexandre Unterstell Banco de Dados I

Prof. Alexandre Unterstell Banco de Dados I Prof. Alexandre Unterstell Banco de Dados I Etapas para o projeto de um BD Análise de requisitos Analista: Entrevista Necessidade do negócio As etapas não consideram ainda nenhuma característica específica

Leia mais

CIn/UFPE Projeto Conceitual de BD - Prof. Robson Fidalgo 1

CIn/UFPE Projeto Conceitual de BD - Prof. Robson Fidalgo 1 CIn/UFPE Projeto Conceitual de BD - Prof. Robson Fidalgo 1 Projeto Conceitual de BD Transformação ER/Relacional Por: Robson do Nascimento Fidalgo rdnf@cin.ufpe.br CIn/UFPE Projeto Conceitual de BD - Prof.

Leia mais

CICLO DE VIDA DE UM BD

CICLO DE VIDA DE UM BD BANCO DE DADOS Universidade do Estado de Santa Catarina Centro de Ciências Tecnológicas Departamento de Ciência da Computação Prof. Alexandre Veloso de Matos alexandre.matos@udesc.br CICLO DE VIDA DE UM

Leia mais

Profa. Daniela Barreiro Claro

Profa. Daniela Barreiro Claro Profa. Daniela Barreiro Claro Modelar é criar representações do mundo real A modelagem relacional pode ser representada via MER (Modelo de Entidade Relacionamento) O MER define estruturas e restrições

Leia mais

Disciplina: Unidade III: Prof.: E-mail: Período:

Disciplina: Unidade III: Prof.: E-mail: Período: Encontro 08 Disciplina: Sistemas de Banco de Dados Unidade III: Modelagem Lógico de Dados Prof.: Mario Filho E-mail: pro@mariofilho.com.br Período: 5º. SIG - ADM Relembrando... Necessidade de Dados Projeto

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA - UFSM COLÉGIO AGRÍCOLA DE FREDERICO WESTPHALEN BANCO DE DADOS II

UNIVERSIDADE FEDERAL DE SANTA MARIA - UFSM COLÉGIO AGRÍCOLA DE FREDERICO WESTPHALEN BANCO DE DADOS II UNIVERSIDADE FEDERAL DE SANTA MARIA - UFSM COLÉGIO AGRÍCOLA DE FREDERICO WESTPHALEN BANCO DE DADOS II BANCO DE DADOS II AULA 1 Linguagem SQL Linguagem de definição de dados (DDL) DISCIPLINA: Banco de Dados

Leia mais

Banco de Dados I 2007. Módulo II: Modelagem Entidade- Relacionamento versus Relacional. (Aula 3) Clodis Boscarioli

Banco de Dados I 2007. Módulo II: Modelagem Entidade- Relacionamento versus Relacional. (Aula 3) Clodis Boscarioli Banco de Dados I 2007 Módulo II: Modelagem Entidade- Relacionamento versus Relacional (Aula 3) Clodis Boscarioli Agenda: Exercícios de Mapeamento ME-R para MR; Restrições de Domínio; Restrições de Chave

Leia mais

Aula VI -MODELO RELACIONAL

Aula VI -MODELO RELACIONAL Aula VI -MODELO RELACIONAL ModeloRelacional É constituído de tabelas, ou relações. Para cada tabela deve haver um nome único. Uma tabela pode ser considerada como um tipo de relação matemática. Uma tabela

Leia mais

Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br

Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Programação com acesso a BD Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br 1 Agenda Introdução Conceitos do Modelo Relacional Restrições de Integridade Básicas Esquema do BD Relacional Restrições

Leia mais

Curso de Aprendizado Industrial Desenvolvedor WEB. Disciplina: Banco de Dados Professora: Cheli Mendes Costa Modelo de Dados

Curso de Aprendizado Industrial Desenvolvedor WEB. Disciplina: Banco de Dados Professora: Cheli Mendes Costa Modelo de Dados Curso de Aprendizado Industrial Desenvolvedor WEB Disciplina: Banco de Dados Professora: Cheli Mendes Costa Modelo de Dados Modelo para organização dos dados de um BD. define um conjunto de conceitos para

Leia mais

ENGENHARIA DA COMPUTAÇÃO BANCO DE DADOS I CONTEÚDO 5 ABORDAGEM RELACIONAL

ENGENHARIA DA COMPUTAÇÃO BANCO DE DADOS I CONTEÚDO 5 ABORDAGEM RELACIONAL ENGENHARIA DA COMPUTAÇÃO BANCO DE DADOS I CONTEÚDO 5 ABORDAGEM RELACIONAL PROF. MS C. RICARDO ANTONELLO WWW.ANTONELLO.COM.B R PORQUE SER RELACIONAL? Hoje, há um claro predomínio dos SGBD relacionais, principalmente

Leia mais

BANCO DE DADOS. Fixação dos conteúdos Integridade Referencial Normalização Exercícios

BANCO DE DADOS. Fixação dos conteúdos Integridade Referencial Normalização Exercícios BANCO DE DADOS Fixação dos conteúdos Integridade Referencial Normalização Exercícios BANCO DE DADOS X SGBD Banco de Dados: Um "banco de dados" pode ser definido como um conjunto de "dados" devidamente

Leia mais

Banco de Dados Modelo Entidade-Relacionamento. Frederico D. Bortoloti freddb@ltc.ufes.br

Banco de Dados Modelo Entidade-Relacionamento. Frederico D. Bortoloti freddb@ltc.ufes.br Banco de Dados Modelo Entidade- Frederico D. Bortoloti freddb@ltc.ufes.br Modelo Entidade- Proposto por Peter Chen, em 1976 Baseado na percepção do mundo real Consiste de um conjunto de objetos básicos

Leia mais

O modelo de dados relacional e as restrições de um banco de dados relacional

O modelo de dados relacional e as restrições de um banco de dados relacional O modelo de dados relacional e as restrições de um banco de dados relacional Vitor Valerio de Souza Campos Modelo de dados relacional OBJETIVOS Apresentar os conceitos do Modelo Relacional Apresentar as

Leia mais

Modelo Relacional. Modelo Relacional. Conceitos Gerais: Relação

Modelo Relacional. Modelo Relacional. Conceitos Gerais: Relação Modelo Relacional Fernanda Baião UNIRIO Material parcialmente extraído a partir das notas de aula de Maria Luiza M. Campos, Arnaldo Rocha e Maria Cláudia Cavalcanti Modelo Relacional Modelo Lógico: ferramenta

Leia mais

Ciclo de vida de um banco de dados relacional

Ciclo de vida de um banco de dados relacional Ciclo de vida de um banco de dados relacional 1. Formulação e análise de requisitos: a) Relacionamentos naturais entre os dados (independentes de processo). b) Requisitos de uso (dependentes de processo).

Leia mais

MSc. Daniele Carvalho Oliveira

MSc. Daniele Carvalho Oliveira MSc. Daniele Carvalho Oliveira AULA 2 Administração de Banco de Dados: MSc. Daniele Oliveira 2 CONCEITOS FUNDAMENTAIS DE BANCO DE DADOS Administração de Banco de Dados: MSc. Daniele Oliveira 3 Conceitos

Leia mais

Modelo de Dados. Modelos Conceituais

Modelo de Dados. Modelos Conceituais Modelo de Dados Modelo para organização dos dados de um BD define um conjunto de conceitos para a representação de dados exemplos: entidade, tabela, atributo,... existem modelos para diferentes níveis

Leia mais

Modelo Entidade-Relacionamento

Modelo Entidade-Relacionamento Modelo Entidade-Relacionamento Banco de Dados I Fases do Projeto jt de BD Enunciado de requisitos entrevista com o usuário do banco de dados para entender e documentar seus requerimentos de dados. Projeto

Leia mais

Banco de Dados. Arquitetura e Terminologia. Prof. Walteno Martins Parreira Jr www.waltenomartins.com.br waltenomartins@yahoo.

Banco de Dados. Arquitetura e Terminologia. Prof. Walteno Martins Parreira Jr www.waltenomartins.com.br waltenomartins@yahoo. Banco de Dados Arquitetura e Terminologia Prof. Walteno Martins Parreira Jr www.waltenomartins.com.br waltenomartins@yahoo.com 2015 Modelo de Dados e Esquemas O modelo de Banco de Dados é como um detalhamento

Leia mais

2008.1 SQL. Autor: Renata Viegas

2008.1 SQL. Autor: Renata Viegas SQL Autor: Renata Viegas A linguagem SQL SQL - Structured Query Language. Foi definida nos laboratórios de pesquisa da IBM em San Jose, California, em 1974. Teve seus fundamentos no modelo relacional Sua

Leia mais

Modelo de Dados Relacional Restrições de um Banco de Dados Relacional

Modelo de Dados Relacional Restrições de um Banco de Dados Relacional Modelo de Dados Relacional e as Restrições de um Banco de Dados Relacional Modelo de Dados Relacional Conceitos do Modelo Relacional Representa o banco de dados como uma coleção de relações. Comparação

Leia mais

Banco de Dados Capítulo 2: Modelo Relacional. Bach. em Ciência da Computação UFPB/CCT Cláudio Baptista, PhD baptista@dsc.ufpb.br

Banco de Dados Capítulo 2: Modelo Relacional. Bach. em Ciência da Computação UFPB/CCT Cláudio Baptista, PhD baptista@dsc.ufpb.br Banco de Dados Capítulo 2: Modelo Relacional Bach. em Ciência da Computação UFPB/CCT Cláudio Baptista, PhD baptista@dsc.ufpb.br 2.1 Histórico Modelo Relacional Foi introduzido por Codd (1970) Tornou-se

Leia mais

GBC043 Sistemas de Banco de Dados. Modelo Relacional (R) Ilmério Reis da Silva ilmerio@facom.ufu.br www.facom.ufu.br/~ilmerio/sbd UFU/FACOM

GBC043 Sistemas de Banco de Dados. Modelo Relacional (R) Ilmério Reis da Silva ilmerio@facom.ufu.br www.facom.ufu.br/~ilmerio/sbd UFU/FACOM GBC043 Sistemas de Banco de Dados Modelo Relacional (R) Ilmério Reis da Silva ilmerio@facom.ufu.br www.facom.ufu.br/~ilmerio/sbd UFU/FACOM UFU/FACOM Página 2 Modelo Relacional R : Definição Def. O MODELO

Leia mais

Modelo Relacional. 2. Modelo Relacional (Lógico)

Modelo Relacional. 2. Modelo Relacional (Lógico) Modelo Relacional 2. Modelo Relacional (Lógico) Derivado do modelo conceitual; Depende do SGBD escolhido; Independe dos dispositivos de armazenamento; Primitivas: tabelas, linhas e colunas; Transformação

Leia mais

MODELAGEM DE DADOS MODELAGEM DE DADOS. rafaeldiasribeiro.com.br 04/08/2012. Aula 7. Prof. Rafael Dias Ribeiro. M.Sc. @ribeirord

MODELAGEM DE DADOS MODELAGEM DE DADOS. rafaeldiasribeiro.com.br 04/08/2012. Aula 7. Prof. Rafael Dias Ribeiro. M.Sc. @ribeirord MODELAGEM DE DADOS PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS Aula 7 Prof. Rafael Dias Ribeiro. M.Sc. @ribeirord 1 Objetivos: Aprender sobre a modelagem lógica dos dados. Conhecer os

Leia mais

Banco de Dados 1 2º Semestre

Banco de Dados 1 2º Semestre Banco de Dados 1 2º Semestre Aula 07 Prof. Gladimir Ceroni Catarino gladimir@gmail.com SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL FACULDADE DE TECNOLOGIA SENAC PELOTAS o Uma coletânea de conceitos que

Leia mais

Modelo de Dados. Modelo para organização dos dados de um BD

Modelo de Dados. Modelo para organização dos dados de um BD Modelo de Dados Modelo para organização dos dados de um BD define um conjunto de conceitos para a representação de dados exemplos: entidade, tabela, atributo,... existem modelos para diferentes níveis

Leia mais

Disciplina de Banco de Dados Parte V

Disciplina de Banco de Dados Parte V Disciplina de Banco de Dados Parte V Prof. Elisa Maria Pivetta CAFW - UFSM Modelo de Dado Relacional O Modelo Relacional O Modelo ER é independente do SGDB portanto, deve ser o primeiro modelo gerado após

Leia mais

PLANO DE ENSINO. PRÉ-REQUISITO: Modelagem e Programação Orientada a Objetos. PROFESSOR RESPONSÁVEL : Josino Rodrigues Neto

PLANO DE ENSINO. PRÉ-REQUISITO: Modelagem e Programação Orientada a Objetos. PROFESSOR RESPONSÁVEL : Josino Rodrigues Neto UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO PRÓ-REITORIA DE ENSINO DE GRADUAÇÃO Rua Dom Manoel de Medeiros, s/n Dois Irmãos 52171-900 Recife-PE Fone: 0xx-81-332060-40 proreitor@preg.ufrpe.br PLANO DE ENSINO

Leia mais

Faculdade Lourenço Filho - ENADE 2011-1

Faculdade Lourenço Filho - ENADE 2011-1 1. Quando se constrói um banco de dados, define-se o modelo de entidade e relacionamento (MER), que é a representação abstrata das estruturas de dados do banco e seus relacionamentos. Cada entidade pode

Leia mais

Desenvolver o projeto conceitual de Banco de dados com a utilização do Modelo Entidade-Relacionamento.

Desenvolver o projeto conceitual de Banco de dados com a utilização do Modelo Entidade-Relacionamento. MODELAGEM DE DADOS USANDO O MODELO ENTIDADE-RELACIONAMENTO Carga horária Quatro horas EAD 3ª semana. Objetivos UNIDADE 2 Desenvolver o projeto conceitual de Banco de dados com a utilização do Modelo Entidade-Relacionamento.

Leia mais

Revisão de Banco de Dados

Revisão de Banco de Dados Revisão de Banco de Dados Fabiano Baldo 1 Sistema de Processamento de Arquivos Antes da concepção dos BDs o registro das informações eram feitos através de arquivos. Desvantagens: Redundância e Inconsistência

Leia mais

2008.1. A linguagem SQL

2008.1. A linguagem SQL SQL 2008.1 A linguagem SQL SQL - Structured Query Language. Foi definida nos laboratórios de pesquisa da IBM em San Jose, California, em 1974. Teve seus fundamentos no modelo relacional Sua primeira versão

Leia mais

MODELO RELACIONAL E RESTRIÇÕES DE INTEGRIDADE

MODELO RELACIONAL E RESTRIÇÕES DE INTEGRIDADE MODELO RELACIONAL E RESTRIÇÕES DE Prof. Ronaldo R. Goldschmidt Definição: O Modelo Relacional representa o banco de dados como uma coleção de relações. Fundamenta-se na Teoria dos Conjuntos. Informalmente:

Leia mais

Fernando Fonseca Ana Carolina

Fernando Fonseca Ana Carolina Banco de Dados Ciclo de Desenvolvimento de Sistemas de BD Investigação dos Dados Modelagem dos Dados Modelagem Conceitual Projeto do Banco de Dados Fernando Fonseca Ana Carolina Implementação do Banco

Leia mais

Modelo Entidade-Relacionamento DCC011. Modelo Entidade-Relacionamento. Processo de Projeto de Bancos de Dados

Modelo Entidade-Relacionamento DCC011. Modelo Entidade-Relacionamento. Processo de Projeto de Bancos de Dados DCC011 Introdução a Banco de Dados -06 Modelo Entidade-Relacionamento Mirella M. Moro Departamento de Ciência da Computação Universidade Federal de Minas Gerais mirella@dcc.ufmg.br Processo de Projeto

Leia mais

1. CONCEITOS BÁSICOS DE BD, SBD E SGBD

1. CONCEITOS BÁSICOS DE BD, SBD E SGBD Introdução 1. CONCEITOS BÁSICOS DE BD, SBD E SGBD A importância da informação para a tomada de decisões nas organizações tem impulsionado o desenvolvimento dos sistemas de processamento de informações.

Leia mais

MODELAGEM DE DADOS. Unidade II Arquiteturas do SGBD

MODELAGEM DE DADOS. Unidade II Arquiteturas do SGBD MODELAGEM DE DADOS Unidade II Arquiteturas do SGBD 0 UNIDADE II: TÓPICOS: Tópico 1 - Arquitetura SGBD Tópico 2 - Etapas de um projeto de Banco de Dados Tópico 3 Modelagem Tópico 1 - Arquitetura SGBD A

Leia mais

UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE)

UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE) UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE) COORDENAÇÃO GERAL DE EDUCAÇÃO A DISTÂNCIA (EAD/UFRPE) Banco de Dados Sandra de Albuquerque Siebra Volume 2 Recife, 2010 Universidade Federal Rural de Pernambuco

Leia mais

Banco de Dados I. Introdução. Fabricio Breve

Banco de Dados I. Introdução. Fabricio Breve Banco de Dados I Introdução Fabricio Breve Introdução SGBD (Sistema Gerenciador de Banco de Dados): coleção de dados interrelacionados e um conjunto de programas para acessar esses dados Coleção de dados

Leia mais

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd.

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd. Apresentação Este curso tem como objetivo, oferecer uma noção geral sobre a construção de sistemas de banco de dados. Para isto, é necessário estudar modelos para a construção de projetos lógicos de bancos

Leia mais

Persistência e Banco de Dados em Jogos Digitais

Persistência e Banco de Dados em Jogos Digitais Persistência e Banco de Dados em Jogos Digitais Prof. Marcos Francisco Pereira da Silva Especialista em Engenharia de Software Jogos Digitais - Computação Gráfica 1 Agenda Vantagens de usar a abordagem

Leia mais

Chaves. Chaves. O modelo relacional implementa dois conhecidos conceitos de chaves, como veremos a seguir:

Chaves. Chaves. O modelo relacional implementa dois conhecidos conceitos de chaves, como veremos a seguir: Chaves 1 Chaves CONCEITO DE CHAVE: determina o conceito de item de busca, ou seja, um dado que será empregado nas consultas à base de dados. É um conceito lógico da aplicação (chave primária e chave estrangeira).

Leia mais

4.6. SQL - Structured Query Language

4.6. SQL - Structured Query Language 4.6. SQL - Structured Query Language SQL é um conjunto de declarações que é utilizado para acessar os dados utilizando gerenciadores de banco de dados. Nem todos os gerenciadores utilizam SQL. SQL não

Leia mais

Banco de Dados I. Aula 12 - Prof. Bruno Moreno 04/10/2011

Banco de Dados I. Aula 12 - Prof. Bruno Moreno 04/10/2011 Banco de Dados I Aula 12 - Prof. Bruno Moreno 04/10/2011 Plano de Aula SQL Definição Histórico SQL e sublinguagens Definição de dados (DDL) CREATE Restrições básicas em SQL ALTER DROP 08:20 Definição de

Leia mais

Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br

Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Banco de Dados Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br 1 Processo de Projeto de Banco de Dados Minimundo Projeto Lógico (Mapeamento do Modelo de Dados) 1 4 Esquema Lógico (Modelo do SGBD)

Leia mais

Gestão de Tecnologia da Informação

Gestão de Tecnologia da Informação Gestão de Tecnologia da Informação Banco de Dados Prof. Gilberto B. Oliveira Tópicos Projeto de Banco de Dados (Button-Up) Modelagem conceitual Modelagem lógica Exemplo: Implementação do modelo Escola

Leia mais

Banco de Dados - Senado

Banco de Dados - Senado Banco de Dados - Senado Modelo Relacional Ilka Kawashita Material preparado :Prof. Marcio Vitorino Abordagem Relacional n Abordagem de modelagem de dados utilizada nos sistemas de gerenciamento de bancos

Leia mais

Introdução Banco de Dados

Introdução Banco de Dados Introdução Banco de Dados Vitor Valerio de Souza Campos Adaptado de Vania Bogorny Por que estudar BD? Os Bancos de Dados fazem parte do nosso dia-a-dia: operação bancária reserva de hotel matrícula em

Leia mais

Introdução a Banco de Dados e Access

Introdução a Banco de Dados e Access Introdução a Banco de Dados e Access Edson Ifarraguirre Moreno Porto Alegre, maio de 2011 Baseado no material da professora Isabel Harb Manssour Roteiro 1. Conceitos Básicos de BD 2. Microsoft Access 3.

Leia mais

Introdução a Banco de Dados e Access

Introdução a Banco de Dados e Access Roteiro Introdução a Banco de Dados e Access Isabel Harb Manssour. Conceitos Básicos B de Banco de Dados. 3. 4. Porto Alegre, maio de 007 Baseado no material das professoras Miriam Sayão, Adriana Beiler

Leia mais

PROJETO DE BANCO DE DADOS -PROJETO CONCEITUAL. Prof. Angelo Augusto Frozza, M.Sc.

PROJETO DE BANCO DE DADOS -PROJETO CONCEITUAL. Prof. Angelo Augusto Frozza, M.Sc. PROJETO DE BANCO DE DADOS -PROJETO CONCEITUAL Prof. Angelo Augusto Frozza, M.Sc. PROJETO CONCEITUAL Levantamento de requisitos Modelagem Conceitual Modelo ER PROJETO CONCEITUAL Parte integrante do Projeto

Leia mais

Banco de Dados I. Introdução Conceitos

Banco de Dados I. Introdução Conceitos Banco de Dados I Introdução Conceitos Prof. Rodrigo Rocha prof.rodrigorocha@yahoo.com Apresentação Prof. Rodrigo Rocha prof.rodrigorocha@yahoo.com Ementa Conceitos Fundamentais de Banco de Dados; Características

Leia mais

Capitulo 2. Prof.º Espc. Fábio Margarito Martins de Barros - Tecnologia de banco de dados

Capitulo 2. Prof.º Espc. Fábio Margarito Martins de Barros - Tecnologia de banco de dados Capitulo 2 1. MODELO LÓGICO DE BANCO DE DADOS... 2 1.1 Definição... 2 1.2 Mapeando o modelo conceitual para o modelo lógico... 2 1.2 Dicionário de dados... 3 2. MODELO FÍSICO DO BANCO DE DADOS... 4 2.1

Leia mais

SQL Linguagem de Definição de Dados. Banco de Dados Profa. Dra. Cristina Dutra de Aguiar Ciferri

SQL Linguagem de Definição de Dados. Banco de Dados Profa. Dra. Cristina Dutra de Aguiar Ciferri SQL Linguagem de Definição de Dados Banco de Dados SQL Structured Query Language Uma das mais importantes linguagens relacionais (se não a mais importante) Exemplos de SGBD que utilizam SQL Oracle Informix

Leia mais

MC536 Bancos de Dados: Teoria e Prática

MC536 Bancos de Dados: Teoria e Prática Universidade Estadual de Campinas - UNICAMP Instituto de Computação - IC MC536 Bancos de Dados: Teoria e Prática Aula #3 : MER e MER Estendido Profs. Anderson Rocha e André Santanchè Campinas, 1 de Agosto

Leia mais

BANCO DE DADOS. info 3º ano. Prof. Diemesleno Souza Carvalho diemesleno@iftm.edu.br www.diemesleno.com.br

BANCO DE DADOS. info 3º ano. Prof. Diemesleno Souza Carvalho diemesleno@iftm.edu.br www.diemesleno.com.br BANCO DE DADOS info 3º ano Prof. Diemesleno Souza Carvalho diemesleno@iftm.edu.br www.diemesleno.com.br BANCO DE DADOS Unidade 1 - Introdução Dados; Banco de Dados; Base de Dados; Projeto de Banco de Dados.

Leia mais

Conceitos de Banco de Dados

Conceitos de Banco de Dados Conceitos de Banco de Dados Autor: Luiz Antonio Junior 1 INTRODUÇÃO Objetivos Introduzir conceitos básicos de Modelo de dados Introduzir conceitos básicos de Banco de dados Capacitar o aluno a construir

Leia mais

Modelagem de Dados UNIDADE DE REVISÃO E RECUPERAÇÃO

Modelagem de Dados UNIDADE DE REVISÃO E RECUPERAÇÃO Modelagem de Dados UNIDADE DE REVISÃO E RECUPERAÇÃO Organizamos esta unidade para orientá-lo na revisão dos conteúdos trabalhados ao longo da disciplina. Siga as orientações desta apresentação, reveja

Leia mais

Faculdade Pitágoras 16/08/2011. Curso Superior de Tecnologia: Banco de Dados Sistemas para Internet

Faculdade Pitágoras 16/08/2011. Curso Superior de Tecnologia: Banco de Dados Sistemas para Internet Faculdade Pitágoras Curso Superior de Tecnologia: Banco de Dados Sistemas para Internet Disciplina: Banco de Dados Prof.: Fernando Hadad Zaidan SQL A linguagem SQL é responsável por garantir um bom nível

Leia mais

Faculdade Pitágoras. Curso Superior de Tecnologia: Banco de Dados. Disciplina: Banco de Dados Prof.: Fernando Hadad Zaidan SQL

Faculdade Pitágoras. Curso Superior de Tecnologia: Banco de Dados. Disciplina: Banco de Dados Prof.: Fernando Hadad Zaidan SQL Faculdade Pitágoras Curso Superior de Tecnologia: Banco de Dados Disciplina: Banco de Dados Prof.: Fernando Hadad Zaidan SQL A linguagem SQL é responsável por garantir um bom nível de independência do

Leia mais

Aula 02 Modelagem de Dados. Banco de Dados. Aula 02 Modelagem de Dados. Superior /2011 Redes Computadores - Disciplina: Banco de Dados -

Aula 02 Modelagem de Dados. Banco de Dados. Aula 02 Modelagem de Dados. Superior /2011 Redes Computadores - Disciplina: Banco de Dados - Banco de Dados Aula 02 Modelagem de Dados Roteiro Definição Evolução Projeto de BD Abstração Esquema e Instância Definição É uma representação, normalmente gráfica, de estruturas de dados reais. Auxilia

Leia mais

MODELAGEM DE DADOS TEORIA E PRÁTICA

MODELAGEM DE DADOS TEORIA E PRÁTICA MODELAGEM DE DADOS TEORIA E PRÁTICA ARAÚJO, M. A. P. 1. INTRODUÇÃO Modelagem de sistemas, tanto a nível funcional quanto de dados, é um requisito fundamental para a obtenção de produtos de software de

Leia mais

Etapas da Elaboração de um Projeto de Banco de Dados

Etapas da Elaboração de um Projeto de Banco de Dados Etapas da Elaboração de um Projeto de Banco de Dados Apresentar os modelos de dados em rede, hierárquicos, relacionais e orientados a objetos. Demonstrar as etapas de desenvolvimento de um projeto de banco

Leia mais

O Modelo de Entidades e Relacionamentos (MER) é um modelo conceitual usado para projeto de aplicações de banco de dados.

O Modelo de Entidades e Relacionamentos (MER) é um modelo conceitual usado para projeto de aplicações de banco de dados. Fases do Projeto de um Banco de Dados Modelo ER O Modelo de Entidades e Relacionamentos (MER) é um modelo conceitual usado para projeto de aplicações de banco de dados. É um modelo baseado na percepção

Leia mais

Empresa de Informática e Informação do Município de Belo Horizonte S/A PRODABEL

Empresa de Informática e Informação do Município de Belo Horizonte S/A PRODABEL Empresa de Informática e Informação do Município de Belo Horizonte S/A PRODABEL Diretoria de Sistema - DS Superintendência de Arquitetura de Sistemas - SAS Gerência de Arquitetura de Informação - GAAS

Leia mais

UNIVERSIDADE VEIGA DE ALMEIDA CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO CURSO SUPERIOR DE TECNOLOGIA EM PROCESSAMENTO DE DADOS BANCO DE DADOS

UNIVERSIDADE VEIGA DE ALMEIDA CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO CURSO SUPERIOR DE TECNOLOGIA EM PROCESSAMENTO DE DADOS BANCO DE DADOS CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO CURSO SUPERIOR DE TECNOLOGIA EM PROCESSAMENTO DE DADOS CLAUDIO RIBEIRO DA SILVA MARÇO 1997 2 1 - CONCEITOS GERAIS DE 1.1 - Conceitos Banco de Dados - Representa

Leia mais

Administração de Bancos de Dados

Administração de Bancos de Dados Modelo Entidade-Relacionamento Prof. Rodrigo M. Silva Administração de Bancos de Dados 1 silvars@gmail.com Plano de Aula Modelos de Dados (Revisão) O Modelo Entidade-Relacionamento Entidades Atributos

Leia mais

MEMOREX BANCO DE DADOS por Paulo Marcelo

MEMOREX BANCO DE DADOS por Paulo Marcelo MEMOREX BANCO DE DADOS por Paulo Marcelo paulo1410@hotmail.com 10/10/2009 Esse é o terceiro memorex destinado aos concurseiros de TI. Neste material, foram compilados os principais conceitos sobre banco

Leia mais

Introdução. Banco de dados. Por que usar BD? Por que estudar BD? Exemplo de um BD. Conceitos básicos

Introdução. Banco de dados. Por que usar BD? Por que estudar BD? Exemplo de um BD. Conceitos básicos Introdução Banco de Dados Por que usar BD? Vitor Valerio de Souza Campos Adaptado de Vania Bogorny 4 Por que estudar BD? Exemplo de um BD Os Bancos de Dados fazem parte do nosso dia-a-dia: operação bancária

Leia mais

Modelo Relacional. Modelo Relacional. Modelo Relacional. Banco de Dados. Modelo Relacional. Modelo Relacional

Modelo Relacional. Modelo Relacional. Modelo Relacional. Banco de Dados. Modelo Relacional. Modelo Relacional Banco de Dados Definido por E F Codd em 1970, teve sua grande aceitação comercial a partir de meados da década de 1980 Razões da grande aceitação Simplicidade dos conceitos básicos Poder dos operadores

Leia mais

Principal: construir uma base de dados para produção de informações sobre internações hospitalares;

Principal: construir uma base de dados para produção de informações sobre internações hospitalares; Principal: construir uma base de dados para produção de informações sobre internações hospitalares; Específicos: - criar um banco de dados para armazenar registros sobre internações hospitalares; - produzir

Leia mais

OBJETIVOS. Orientações para Projetos de BD; Dependências Funcionais (DFs): Definição de DF; Regras de inferência para DFs.

OBJETIVOS. Orientações para Projetos de BD; Dependências Funcionais (DFs): Definição de DF; Regras de inferência para DFs. BANCO DE DADOS Universidade do Estado de Santa Catarina Centro de Ciências Tecnológicas Departamento de Ciência da Computação Prof. Alexandre Veloso de Matos alexandre.matos@udesc.br OBJETIVOS Orientações

Leia mais

Integridade dos Dados

Integridade dos Dados 1 Integridade dos Dados Integridade dos Dados Melissa Lemos melissa@inf.puc-rio.br A integridade dos dados é feita através de restrições, que são condições obrigatórias impostas pelo modelo. Restrições

Leia mais

Modelo Entidade-Relacionamento. Prof. Antonio Almeida de Barros Jr.

Modelo Entidade-Relacionamento. Prof. Antonio Almeida de Barros Jr. Modelo Entidade-Relacionamento Prof. Antonio Almeida de Barros Jr. Conteúdo Contexto Histórico A Importância da Modelagem de Dados Projeto de Banco de Dados Modelagem Conceitual Projeto Lógico Projeto

Leia mais

Disciplina: Unidade II: Prof.: E-mail: Período:

Disciplina: Unidade II: Prof.: E-mail: Período: Encontro 03 Disciplina: Sistemas de Banco de Dados Unidade II: Modelagem Conceitual de Dados Prof.: Mario Filho E-mail: pro@mariofilho.com.br Período: 5º. SIG - ADM 2. Modelagem Conceitual de Dados (Modelo

Leia mais

INTRODUÇÃO. Diferente de Bando de Dados

INTRODUÇÃO. Diferente de Bando de Dados INTRODUÇÃO Diferente de Bando de Dados 1 INTRODUÇÃO DADOS São fatos conhecidos que podem ser registrados e que possuem significado. Ex: venda de gasolina gera alguns dados: data da compra, preço, qtd.

Leia mais

BANCO DE DADOS E BUSINESS INTELIGENCE. C/H: 20 horas (20/02, 25/02, 27/02, 04/03, 06/03)

BANCO DE DADOS E BUSINESS INTELIGENCE. C/H: 20 horas (20/02, 25/02, 27/02, 04/03, 06/03) MBA em Gestão de TI MÓDULO: BANCO DE DADOS E BUSINESS INTELIGENCE C/H: 20 horas (20/02, 25/02, 27/02, 04/03, 06/03) PROFESSOR: Edison Andrade Martins Morais prof@edison.eti.br http://www.edison.eti.br

Leia mais

Introdução à Banco de Dados

Introdução à Banco de Dados Introdução à Banco de Dados Introdução à Banco de Dados Agenda O que é Banco de Dados Como ele funciona Sistema Gerenciador de Banco de Dados Modelagem de Dados Modelo de dados Entidade-Relacionamento

Leia mais

Tecnologias e Linguagens para Banco de Dados I. Expressão do Relacionamento. Expressão do Relacionamento

Tecnologias e Linguagens para Banco de Dados I. Expressão do Relacionamento. Expressão do Relacionamento Tecnologias e Linguagens para Banco de Dados I Efetivação Lógica de Normalização Prof. Gilberto Braga de Oliveira Expressão do Relacionamento Necessidade de incluir campos nas tabelas para que os relacionamentos

Leia mais

Plano de Ensino. Apresentação da Unidade Curricular

Plano de Ensino. Apresentação da Unidade Curricular Plano de Ensino Plano de Ensino Apresentação da Unidade Curricular o Funcionamento, arquitetura e conceitos fundamentais dos bancos de dados relacionais e objeto relacionais. Utilização de linguagem DDL

Leia mais

Banco de Dados Lista de Exercícios 01

Banco de Dados Lista de Exercícios 01 Banco de Dados Lista de Exercícios 01 Prof. Anderson Rocha & Prof. André Santanché Campinas, 24 de Setembro de 2012 Nome: RA: 1 Observações Este lista contem 20 exercícios e contempla os seguintes assuntos

Leia mais

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos Conceitos Básicos Introdução Banco de Dados I Prof. Guilherme Tavares de Assis Universidade Federal de Ouro Preto UFOP Instituto de Ciências Exatas e Biológicas ICEB Departamento de Computação DECOM Dados

Leia mais

Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br

Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Programação com acesso a BD Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br 1 Modelos de Dados, Esquemas e Instâncias 2 Modelos de Dados, Esquemas e Instâncias Modelo de dados: Conjunto de conceitos

Leia mais

UNIVERSIDADE FEDERAL DO MARANHÃO - UFMA. Banco de Dados II. Integridade. Carlos Eduardo Portela Serra de Castro

UNIVERSIDADE FEDERAL DO MARANHÃO - UFMA. Banco de Dados II. Integridade. Carlos Eduardo Portela Serra de Castro UNIVERSIDADE FEDERAL DO MARANHÃO - UFMA Banco de Dados II Integridade Carlos Eduardo Portela Serra de Castro * Integridade Introdução Restrições de Integridade de Domínio de Relação Asserções Procedimentos-gatilho

Leia mais

Técnicas e Linguagens para Banco de Dados I

Técnicas e Linguagens para Banco de Dados I Técnicas e Linguagens para Banco de Dados I Prof. Eduardo Ribeiro www.eduardo.trisolution.com.br eduardo@ trisolution.com.br Introdução Banco de Dados Dados x Informações Dados = É um elemento que mantém

Leia mais

Prof. Marcelo Machado Cunha www.marcelomachado.com mcelobr@yahoo.com.br

Prof. Marcelo Machado Cunha www.marcelomachado.com mcelobr@yahoo.com.br Prof. Marcelo Machado Cunha www.marcelomachado.com mcelobr@yahoo.com.br Ementa Introdução a Banco de Dados (Conceito, propriedades), Arquivos de dados x Bancos de dados, Profissionais de Banco de dados,

Leia mais

14/08/2008. Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan

14/08/2008. Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan Faculdade INED Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional 1 Prof.: Fernando Hadad Zaidan 1 Unidade 2 Introdução a SQL 2 Leitura Obrigatória ELMASRI,

Leia mais

Modelagem de Dados Usando o Modelo Entidade-Relacionamento

Modelagem de Dados Usando o Modelo Entidade-Relacionamento Usando o Modelo Entidade-Relacionamento MER 1 MER Levantamento e Análise de requisitos Entrevista Entender e documentar seus requisitos de dados Requisitos funcionais da aplicação empregadas ao banco de

Leia mais

Introdução ao SQL. O que é SQL?

Introdução ao SQL. O que é SQL? Introdução ao SQL 1 O que é SQL? Inicialmente chamada de Sequel, SQL (Structured Query Language), é a linguagem padrão utilizada para comunicar-se com um banco de dados relacional. A versão original foi

Leia mais

04/08/2012 MODELAGEM DE DADOS. PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS. Aula 2. Prof. Rafael Dias Ribeiro. M.Sc.

04/08/2012 MODELAGEM DE DADOS. PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS. Aula 2. Prof. Rafael Dias Ribeiro. M.Sc. MODELAGEM DE DADOS PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS Aula 2 Prof. Rafael Dias Ribeiro. M.Sc. @ribeirord 1 Objetivos: Revisão sobre Banco de Dados e SGBDs Aprender as principais

Leia mais

Figura. Sistema de Banco de Dados. Portanto, a assertiva C é a resposta da questão. Prof a. Patrícia Lima Quintão www.pontodosconcursos.com.

Figura. Sistema de Banco de Dados. Portanto, a assertiva C é a resposta da questão. Prof a. Patrícia Lima Quintão www.pontodosconcursos.com. Resolução da Prova de Conhecimentos de Bancos de Dados Olá, pessoal! A seguir destacamos a resolução da prova realizada em 17/06, para a área: Auditoria e Fiscalização, Campo de Atuação: Geral, da Controladoria-Geral

Leia mais

Banco de Dados I Introdução

Banco de Dados I Introdução Banco de Dados I Introdução Prof. Moser Fagundes Curso Técnico em Informática (Modalidade Integrada) IFSul Campus Charqueadas Sumário da aula Avaliações Visão geral da disciplina Introdução Histórico Porque

Leia mais

Exercícios de Lógica Exercícios de Fixação 08

Exercícios de Lógica Exercícios de Fixação 08 Exercícios Exercícios de Lógica Exercícios de Fixação 08 1. A linguagem SQL apresenta uma série de comandos que permitem a definição dos dados, chamada de DDL (Data Definition Language). Assinale a alternativa

Leia mais

SISTEMAS DE BANCO DE DADOS. Prof. Adriano Pereira Maranhão

SISTEMAS DE BANCO DE DADOS. Prof. Adriano Pereira Maranhão SISTEMAS DE BANCO DE DADOS Prof. Adriano Pereira Maranhão 1 REVISÃO BANCO DE DADOS I O que é banco de dados? Ou seja afinal o que é um SGBD? REVISÃO BD I REVISÃO DE BD I Um Sistema de Gerenciamento de

Leia mais