refinamento do modelo relacional

DISCIPLINA: MODELAGEM DA INFORMAÇÃO
CÓDIGO/CRÉDITOS/TURMA(S):
PROFESSOR: CLAUDIO SONALGIO ALBANO
ANO LETIVO/SEMESTRE: 2009 – SEGUNDO
II – EMENTA
Conceitos, importância e objetivos da modelagem de informações. Esquemas e mapeamentos. Linguagens
de definição, manipulação e consultas. Modelo relacional. Utilização de comandos básicos de linguagem
SQL. Recuperação, segurança e integridade.
III - OBJETIVO(S)
Ao final o aluno deverá ser capaz de identificar aspectos relevantes da armazenagem e recuperação de
informações. Desenvolver uma modelagem conceitual e lógica visando à construção de uma base de dados,
e utilizar uma ferramenta para a implementação do modelo.
IV – CONTEÚDO PROGRAMÁTICO
01.) MODELAGEM: Conceitos, importância e objetivos.
02.) BANCO DE DADOS: Sistemas, tipos e vantagens.
03.) MODELAGEM CONCEITUAL: Entidades e relacionamentos. Restrições e mapeamentos. Chaves.
Generalizações e agregações.
04.) CONSTRUÇÃO DE MODELOS DE BANCO DE DADOS: Criação base de dados, usuários, tabelas
e restrições.
05.) ARMAZENAMENTO E RECUPERAÇÃO DE INFORMAÇÕES: Comandos da Linguagem SQL.
V – METODOLOGIA
Aulas expositivo-dialogadas, seminários para apresentação de trabalhos, trabalhos em grupo com relatórios,
estudos de caso e apresentação de relatos de leituras.
TÉCNICAS
RECURSOS
Aulas expositivo-dialogadas
Apostila, slides, quadro e data-show.
Seminários para apresentação de trabalhos
Quadro, slides e data-show.
Trabalhos em grupo com relatórios
Artigos, textos de livros, revistas, jornais, internet
e filmes..
Estudos de caso
Textos de livros.
Apresentação relatórios de leituras
Artigos, textos de livros, revistas, jornais e
internet.
Visitas técnicas.
Visita a empresas, com atividades inerentes a
disciplina e curso.
VI – CRONOGRAMA DE ATIVIDADES
Modelagem.
1 aula – Apresentação do professor, disciplina e conteúdo. Conceitos de modelagem.
Banco de dados.
2 aula – Banco de dados: Sistemas, tipos e vantagens.
Modelagem Conceitual e Construção de Modelos de Banco de Dados.
3 aula – Entidades e relacionamentos.
4 aula – Restrições e mapeamentos, chaves.
5 aula – Exercícios de revisão de conteúdo e construção de um modelo simples.
6 aula – Exercícios práticos de implementação do modelo.
7 aula – Generalizações e agregações.
8 aula – Exercícios práticos de implementação do modelo.
9 aula – Prova.
10 aula – Comandos de armazenamento e recuperação de informações.
11 aula - Exercícios práticos de implementação do modelo.
12 aula – Recuperação de informações através de comando SQL.
13 aula – Construção de relatórios e exportação de informações com comandos SQL.
14 aula - Exercícios práticos com o modelo implementado.
15 aula - Exercícios práticos com o modelo implementado.
16 aula – Prova .
Recuperação.
17 aula – Atividades de recuperação.
VII – CRITÉRIOS DE AVALIAÇÃO
Assiduidade, pontualidade e participação em sala de aula.
Avaliação Diagnóstica: Não utilizada.
Avaliação Formativa: Trabalhos que visam identificar a assimilação de conteúdos considerados mais
importantes para a disciplina. Peso 3 ao final do semestre, para formar a média. O aluno deverá realizar
metade dos trabalhos, caso contrário não terá a nota dos trabalhos somada a média, ficando com ZERO
neste item. O professor avisará previamente quando da realização de trabalhos.
Avaliação Somativa: Uma avaliação (prova) por bimestre. Cada prova terá peso 3,5 ao final do semestre
para formar a média. O aluno que não realiza uma prova ficará com nota ZERO nesta prova.
Atividades de Recuperação devem ser previstas.
Ao final do semestre o aluno que não alcançar a média 6, poderá realizar uma atividade de recuperação
com todo o conteúdo do semestre. Com esta prova o aluno substituirá a menor nota de uma das provas, e
deverá ter nota suficiente para alcançar a média 6, somando a outra prova e a nota dos trabalhos.
VIII – REFERÊNCIAS BÁSICAS
Exemplares
Cougo, Paulo. Modelagem conceitual e projeto de Banco de dados. São Paulo. Editora
00
Campus. 2004.
BOOCH, Grady, JACOBSON, Ivar & RUMBAUGH James. UML Essencial. Um breve
00
guia para a linguagem-padrão de modelagem de objetos.
Exemplares
IX - REFERÊNCIAS COMPLEMENTARES
SETZER, V. W. Banco de Dados: Conceitos, modelos, gerenciadores, projeto lógico e
00
projeto físico. Editora Edgard Blucher. 1999. 2 Edição.
HEUSER, Carlos Alberto. Projeto de Banco de Dados. Editora Sagra-Luzzatto. Porto
00
Alegre. 2004. 2
MODELAGEM DE INFORMAÇÕES
No mundo real temos diversos objetos, cada objeto com sua função e características. Para que o
“mundo real” seja representado em sistemas informatizados, precisamos abstrair estas características e
funcionalidades de cada objeto.
Entretanto técnicas de modelagem não se aplicam única e exclusivamente a informática, podem ser
úteis para outras finalidades, para modelar processos, para área de organização e métodos, entre outras.
Devemos entender algumas premissas antes de iniciarmos o processo de modelagem, tais como:
como devemos modelar, por que devemos modelar, para que serve o modelo depois de modelado e o que
deve conter o modelo.
Para um correto processo de modelagem são necessários alguns procedimentos, tais como: observar,
elaborar conceitos, caracterizar, abstrair características, representar, definir e saber como manipular os
elementos ou objetos do mundo real.
Podemos perceber que modelar é um processo estruturado, pois devemos realizar uma série de
procedimentos, todos têm uma ordem e regras próprias.
Processo de modelagem
A obtenção de um modelo apartir de um conjunto de objetos observados deve considerar também
alguns quesitos, pela ordem estes quesitos devem ser:
Especificação dos requisitos => devemos definir a abrangência do trabalho, nível de detalhamento
desejado, tempo e recursos disponíveis.
Execução da modelagem => após as definições anteriores, devemos efetivamente começar o
processo de modelagem, para isto devemos observar os objetos, entender, representar, verificar a fidelidade e
coerência e finalmente validar nosso modelo..
Níveis de modelagem
Existem três níveis de modelagem, que são os seguintes:
Conceitual: quando os objetos, suas características e relacionamentos têm uma representação fiel ao
ambiente. Deve ser o modelo usado para o nível de conversação, entendimento, transmissão, validação de
conhecimentos e mapeamento do ambiente.
Lógico: quando os objetos têm suas características e relacionamentos representados de acordo com
as limitações impostas pela tecnologia a ser utilizada.
Físico: quando efetivamente implementamos o modelo em um SGBD.
01.) BANCO DE DADOS: Sistemas, tipos e vantagens.
SGBD (Sistema gerenciador de Banco de Dados).
Conceito (KORTH & SILBERSCHATZ) “é um conjunto de dados associados a um conjunto de programas
para acessar estes dados. O conjunto de dados, chamado banco de dados, contém informações sobre uma
empresa em particular. O principal objetivo de um SGBD é proporcionar um ambiente conveniente e
eficiente para o armazenamento e recuperação das informações”.
São projetados para manipular e gerenciar um grande volume de informações. Para poderem
realizar de forma eficaz estas tarefas, possuem mecanismos de definição das estruturas e de manipulação
destas informações (acesso, segurança, integridade, etc ...).
Atualmente, devido à importância das informações para as organizações, os SGBD,
assumem um papel de destaque no cenário tecnológico.
Objetivo de um SGBD:
“E proporcionar aos usuários uma visão abstrata dos dados. Isto é, o sistema esconde
determinados detalhes de como os dados são mantidos e como estão armazenados”.
Tipos de Gerenciadores de Banco de dados:
- Relacionais
- Orientados a objetos.
Vantagens:
Inconsistência e redundância de dados:
Uma informação pode aparecer (constar) duas ou mais vezes no sistema (em mais de um arquivo).
Dificuldade no acesso aos dados:
Facilidade para desenvolver novas consultas e relatórios.
Problemas de segurança:
Controlar acesso dos usuários as informações.
Acesso concorrente:
Dois ou mais usuários acessaram a mesma informação simultaneamente.
Problemas na Integridade:
Permitir que valores incorretos sejam armazenados na base de dados do sistema.
Problemas de atomicidade:
Garantir que toda uma transação seja efetuada.
Modelos de Banco de Dados (Alguns autores preferem “a visão”):
Um modelo de banco de dados é a descrição dos tipos de informações que estão armazenadas em um
banco de dados. Para construirmos um modelo de banco de dados, usamos uma linguagem de modelagem de
dados. A representação deste modelo é o esquema do banco de dados.
Modelo = descrição formal da estrutura de um banco de dados.
O modelo mostra qual o tipo de informação está armazenado, mas não quais as informações.
Modelo Conceitual: É a descrição do banco de dados de forma independente do SGBD.
Modelo Lógico: É a descrição do banco de dados no nível de abstração visto pelo usuário. Este
modelo é dependente do tipo de SGBD, utilizado.
03.) Modelagem Conceitual e Construção de Modelos de Banco de Dados.
ENTIDADE-RELACIONAMENTO
O modelo entidade-relacionamento (E-R) tem por base a percepção de que o mundo real é formando
por um conjunto de objetos chamados de entidades e pelo conjunto de relacionamentos entre esses objetos.
Conceitos Básicos
Existem três noções básicas empregadas pelo modelo E-R, que são as seguintes: Entidades,
relacionamentos e atributos.
Conjunto de Entidades.
Uma entidade é uma “coisa” ou “objeto” do mundo real, que pode identificada de forma unívoca em
relação a todos os outros objetos. Exemplo: Cada pessoa é uma entidade dentro de uma empresa.
Uma entidade tem um conjunto de propriedades, e os valores para algumas propriedades devem ser
únicos. Exemplo: Cada pessoa deve ter seu CPF, que deve ser um número único.
Então um conjunto de entidades é um conjunto que abrange entidades de mesmo tipo que
compartilham as mesmas propriedades, que são os atributos. Exemplo: O conjunto dos alunos da Unipampa
deve ser definido como o conjunto de entidades alunos.
Atributos: Uma entidade é representada por um conjunto de atributos. Atributos são propriedades
descritivas de cada membro de um conjunto de entidades. Isto quer dizer que o banco de dados mantém
informações similares de cada uma das entidades do conjunto entidades. Entretanto cada entidade pode (e
deverá) ter seu próprio valor em cada atributo. Para cada atributo existe um conjunto de valores possíveis, o
que chamamos de domínio, ou conjunto de valores do atributo. Exemplo: O domínio do atributo sexo do
aluno poderá ser M ou F, com um caractere.
Resumindo: Um banco de dados inclui uma coleção de conjuntos de entidades, cada qual contendo
um número de entidades de mesmo tipo. Cada entidade possui um conjunto de atributos.
Um atributo, por ser caracterizado pelos seguintes tipos:
Atributo Simples: Quando o atributo não é dividido. Exemplo: Sexo.
Atributo Composto: Quando atributo é dividido, ou pode ser uma união de diversos atributos.
Exemplos: Endereço, que pode ser composto de rua, número, bairro, cep, cidade, etc...
Atributo Mono-Valorado: Quando podem assumir apenas um valor. Exemplo: Número da matricula
do aluno.
Atributo Multivalorado: Quando podem assumir dois ou mais valores. Exemplo: Nome dos dependentes de
um funcionário de uma empresa. A multi-valoração pode ter limites ou não.
Atributos Nulos: Quando é possível um determinado atributo não ter valor. Exemplo: Nome do
cônjuge.
Atributos Derivados: Quando um atributo é derivado de outro atributo da mesma entidade ou de
outra entidade, e estão relacionados entre si. Exemplo: Número de disciplinas cursadas pelo aluno no
semestre.
RELACIONAMENTOS
Um relacionamento é uma associação entre duas ou mais entidades.
Também podemos dizer que um relacionamento é igual a um conjunto de associações entre
entidades.
Em um banco de dados normalmente temos relacionamentos binários (entre duas entidades), mas os
relacionamentos podem envolver mais de duas entidades, então estes são os relacionamentos ternários.
CARDINALIDADES
O mapeamento das cardinalidades expressa o número de entidades às quais outra entidade pode estar
associada por um conjunto de relacionamentos.
Podemos ter as seguintes cardinalidades:
Um para Um: Uma entidade em (A) está associada no máximo a uma entidade em (B) e vice-versa.
Um para muitos: Uma entidade em (A) está associada à várias entidades em (B), entretanto uma
entidade em (B) está associada no máximo a uma entidade em (A) .
Muitos para Um: Uma entidade em (A) está associada a uma entidade em (B), entretanto uma
entidade em (B) está associada à várias entidades em (A) .
Muitos para Muitos: Uma entidade em (A) está associada á várias entidades em (B) e vice-versa.
No projeto de um banco de dados uma propriedade importante de um relacionamento é o que
chamamos de cardinalidade.
Cardinalidade expressa o número (mínimo, máximo) de ocorrências de entidades associadas a uma
ocorrência da entidade em questão através do relacionamento.
IDENTIFICANDO ENTIDADES
Toda entidade deve possuir um identificador (chave).
Um identificador é um conjunto de um ou mais atributos, cujos valores servem para distinguir uma
entidade dentro do conjunto das entidades, ou seja, tornar esta entidade única.
Identificadores devem ser únicos, ou seja, não podem ser informações que possam existir em duas
entidades de um mesmo conjunto.
Exemplo: Nome, endereços e outros.
Exemplos de identificadores: Matricula do aluno, CPF, CGC e outros.
Exemplos de identificadores duplos: As placas de automóveis antigamente no Brasil, pois era preciso o
conjunto de letras, números e estado para identificar um automóvel.
Os atributos para identificaram uma entidade devem obedecer a duas premissas básicas:
Deve ser mínimo: Não devemos unir ou agrupar identificadores desnecessários, quando apenas um
identificador é suficiente para identificar uma entidade. Exemplo: Para identificar uma entidade aluno, basta
sua matricula, não é necessário unir matricula e carteira de identidade.
Deve ser único para cada entidade: Existem casos (algumas entidades) que mais de um atributo
poderia ser o identificador, mas o administrador do banco de dados deve escolher apenas um. Exemplo: Para
identificar uma empresa pode ser usado o CGC ou a inscrição estadual.
ENTIDADES DEPENDENTES
È quando uma entidade para existir, ou estiver presente no banco necessita de outra, sem a qual ela
não faz sentido. Exemplos: Funcionário e seus dependentes, pois os dependentes não representam nada para
o banco se não estiverem relacionados com os funcionários.
ENTIDADES FRACAS
È quando uma entidade, embora tenha atributos significativos, não possui nenhum atributo com
características de identificador da entidade ou que seja uma chave.
Exemplos: No sistema de folha de pagamento os valores correspondentes aos créditos e débitos mensais de
um funcionário, ou seja, seu extrato mensal de vencimentos.
IDENTIFICANDO RELACIONAMENTOS
Uma ocorrência de relacionamento geralmente diferencia-se das demais do mesmo relacionamento
por alguns atributos que dela participam e que são diferentes.
Exemplo: Relacionamento aluno – disciplina – professor.
Mas podem ocorrer casos, que este relacionamento se repita, se o aluno repetir a disciplina com o
mesmo professor?
Então será necessário criar um atributo para identificar este relacionamento no exemplo, poderia ser
o semestre.
Semestre seria então um atributo identificador de relacionamento.
GENERALIZAÇÃO E ESPECIALIZAÇÃO.
É possível desmembrar uma entidade genérica em entidades especializadas.
Aliado a estes conceitos de generalização ou especialização temos o conceito de herança de
propriedades, onde “herdar propriedades” significa que a entidade especializada possui além de suas
próprias características (atributos, relacionamentos, identificadores), também possui as características da
própria genérica.
A generalização/especialização pode ser classificada em dois tipos:
- Total: Quando para cada entidade genérica sempre haverá a ocorrência de uma entidade
especializada, ou seja, é obrigatória a existência da entidade especializada. No exemplo uma pessoa, sempre
é uma pessoa física ou jurídica.
- Parcial: Quando não é obrigatória a existência da entidade especializada, ou seja, podemos ter a
entidade geral, mas ter uma entidade especializada para esta entidade geral.
Não existem limites hierárquicos para generalização/especialização, ou seja, uma entidade pode ser
especializada em um nível, mas ser genérica de outro.
ENTIDADE ASSOCIATIVA OU AGREGAÇÃO
Um relacionamento é uma associação entre duas ou mais entidades.
Às vezes é necessário, ou desejável, criarmos um relacionamento que contenha informações.
Então temos que criar uma entidade (somente é possível guardar informações em entidades).
Então pode surgir uma dúvida, esta nova entidade estará relacionada com qual das entidades
que gerou o relacionamento, este fato não está previsto na abordagem E-R.
Para estes casos existe o conceito de abordagem associativa.
REPRESENTAÇÕES GRÁFICAS DE UMA DIAGRAMA E-R.
Entidade: Representa-se por um retângulo.
Relacionamento: Representa-se por um losango.
Relacionamento identificador: Representa-se por um losango, mas a linha que possui o
relacionamento identificador e mais grossa.
Atributo: Representa-se por uma linha com uma bola vazia na ponta.
Atributo identificador: Representa-se por uma linha com uma bola cheia na ponta (chave).
Generalização e especialização: Representamos por um triangulo.
Se for total, temos um t.
Se for parcial, temos um p.
Entidade associativa: Representamos por um losango dentro de um retângulo.
Entidade fraca: Representamos retângulo, que está ligado ao relacionamento com a entidade
forte com uma linha dupla.
IDENTIFICANDO CONSTRUÇÕES
Para podermos construir um modelo ER é necessário conhecer o contexto ou ambiente, no
qual está inserido este modelo. Normalmente um modelo ER, sofre modificações com o transcorrer
do tempo, em especial a medida que o modelador vai conhecendo melhor o contexto, ou seja, vai
desenvolvendo/construindo um aprendizado sobre a realidade, na qual será inserido o DER..
Entretanto existem alguns critérios que devem ser observados para a construção de DER.
- Atributo versus entidade relacionada:
Uma questão bastante comum na modelagem é quando devemos considerar um objeto uma
entidade ou um atributo.
Exemplos: Sexo de um aluno deve ser um atributo ou entidade.
Salário de um funcionário deve ser um atributo ou entidade.
Preço de venda de um produto deve ser atributo ou entidade.
Cor de um automóvel deve ser atributo ou entidade.
Estado civil de uma pessoa deve ser um atributo ou uma entidade.
Existem basicamente dois critérios para realizar esta modelagem:
01.) Se o objeto em questão estiver vinculado a outros objetos (relacionamentos, atributos,
etc..), devemos considera-lo como uma entidade;
02.) Aspectos temporais, ou seja, serão necessárias informações sobre a variação do valor
deste atributo com o transcorrer do tempo, então também devemos considera-lo uma entidade.
- Atributo versus generalização/especialização:
Quando devemos modelar um objeto como atributo ou como uma especialização. Devemos
ter a seguinte regra em mente:
Uma especialização deve ser usada, quando os objetos especializados possuem atributos que
os diferem dos demais objetos da mesma entidade.
- Atributos opcionais e monovalorados
Muitas vezes atributos são opcionais, ou seja, não é obrigatória sua presença na entidade.
Na modelagem devemos restringir a presença de atributos aos obrigatórios e
monovalorados.
CONSTRUINDO MODELOS
- Verificando e validando um modelo:
Um modelo, para se considerado válido e consistente deve obedecer a uma série de
requisitos, que podemos destacar como os seguintes:
01.) Deve ser completo: Para verificar esta qualidade do modelo, devemos ter uma pessoa
que tenha um perfeito conhecimento da realidade em questão, ou seja, da realidade modelada.
02.) Não ser redundante: Devem ser evitadas redundâncias de atributos, geralmente esta
redundância ocorre, quando criamos atributos que guardam valores resultantes de operações sobre
outros atributos ou outras entidades. Exemplo: Atributos com totais de alunos em uma disciplina na
entidade disciplina. Outra redundância é a ocorrência de relacionamentos redundantes.
03.) Aspecto Temporal: Quando estamos construindo um modelo DER, a preocupação
maior e que o modelo reflita uma realidade atual do sistema. Entretanto um banco de dados tende a
se modificar com o transcorrer do tempo, estas modificações podem ser em nível de atributos e
relacionamentos. Estas modificações podem ser em nível de inclusão de informações ou exclusão.
Não existem regras para seguirmos para realizar uma modelagem, entretanto algumas observações
podem ser seguidas e é claro um perfeito entendimento do sistema a ser modelado e suas
possibilidades de modificações com o transcorrer no tempo.
- Atributos que modificam os valores com o tempo: Alguns atributos podem ser
alterados com o tempo, em alguns casos já sabemos de antemão que isto irá acontecer, então
devemos considerar a possibilidade de modelarmos estes atributos como uma entidade. Exemplo:
Salário de um funcionário, nome de um cliente e outros.
- Relacionamento que modificam os valores com o tempo: Quando modelamos uma
empresa, normalmente alocamos um funcionário em uma filial (se a empresa tiver filiais), com o
transcorrer do tempo este funcionário poderá ser transferido para outra filial. Este é um exemplo de
relacionamento que se modificou com o transcorrer do tempo. Num primeiro momento era (1;1), ou
seja um empregado somente podia estar alocado a uma filial, mas com a modificação no sistema,
passou para (n:n), ou seja, aparecerá no relacionamento um empregado em duas filiais, então
devemos colocar o período que ele esteve em cada filial.
- Acesso a dados passados: Para evitar que o banco cresça indefinidamente, podemos
estabelecer critérios para a retirada de informações passadas do banco, entretanto devemos
pensar/estabelecer normas para que sejam efetuadas consultas a estas informações, neste caso
devemos verificar a estrutura do banco como um todo, ou seja, será possível voltar simplesmente as
informações para o banco? Outra forma é retirar estas informações do banco e armazena-las em
forma de dados estatísticos.
ESTRATÉGIAS DE MODELAGEM
O processo de construção de um modelo DER é incremental, ou seja, ele vai sendo
construindo conforme se toma conhecimento da realidade a ser modelada.
Normalmente muitas modificações acontecem durante a confecção de um modelo DER, pois
este vai sendo enriquecido gradativamente, conforme aumenta o conhecimento sobre o sistema,
sendo então necessárias mudanças em processos já definidos.
O processo de construção de um modelo DER, também é um processo de aprendizagem, que
conseqüentemente enriquece o construtor para futuros projetos.
Existem algumas propostas de modelagem de dados, mas nenhuma consegue obter uma
aceitação universal ou firmar-se tecnicamente como a melhor ou mais aceitável. Sendo esta escolha
muito mais uma questão empírica do construtor, de aprendizado ou de adequar-se a uma realidade
momentânea.
Conforme a fonte de informações (onde estão as informações para que possamos modelar o
sistema) podemos especificar duas estratégias de modelagem, que são as seguintes:
- Partindo de descrições de dados já existentes: Existem algumas situações em que esta
estratégia é mais adequada.
- Partindo do conhecimento de pessoas: Normalmente isto ocorre quando os sistemas não
estão informatizados ou possuem poucos documentos ou procedimentos formalizados.
ABORDAGEM RELACIONAL
Um banco de dados relacional é composto de tabelas ou relações. A terminologia tabela é mais
conhecida na prática (mercado profissional) já o termo relações é mais conhecido no meio acadêmico, por
isto a denominação “relacional”.
TABELAS
Uma tabela é um conjunto não ordenado de linhas (tuplas – acadêmico). Cada linha é composta de
uma série de campos (atributos – acadêmico). Cada campo é identificado por um nome. O conjunto de
campos das linhas de um tabela que possuem o mesmo nome formam uma coluna.
CHAVES
Para estabelecermos relações entre as tabelas (entre as linhas de tabelas) de um banco de dados
relacional é o da chave. Existem três tipos de chaves que devemos considerar:
CHAVE PRIMÁRIA. É uma coluna ou combinação de atributos, cujos valores distinguem
uma linha das demais linhas dentro de uma tabela. As chaves primárias podem ser compostas. Uma chave
primária deve ser mínima, ou seja, conter o menor número de atributos necessários.
CHAVE ESTRANGEIRA. É uma coluna ou combinação de atributos, cujos valores
aparecem necessariamente na chave primária de outra tabela. Através da chave estrangeira é que são
efetuados os relacionamentos em BD relacionais. A existência de uma chave estrangeira impõe as seguintes
restrições:
- Quando da inclusão de uma linha na tabela que contem a chave estrangeira, deve ser
garantido que este valor apareça (esteja presente) na tabela no qual é chave primária.
- Quando da alteração da chave estrangeira, deve ser garantido que o novo valor apareça
(esteja presente) na tabela no qual é chave primária.
- Quando da exclusão de uma linha da tabela que contém a chave primária referenciada em
uma tabela como estrangeira, devemos garantir que nesta tabela (onde esta chave era estrangeira) não mais
apareçam valores com esta chave estrangeira.
Uma chave estrangeira pode referenciar valores da mesma tabela.
CHAVE ALTERNATIVA. Em alguns casos mais de uma coluna (combinação de várias
colunas) podem distinguir uma linha de outra em uma tabela. Quando estas colunas não são
chaves primárias, então eles são chaves alternativas. Os valores das chaves alternativas podem ser
repetidos em uma tabela ou não.
DOMINIOS E VALORES VAZIOS
Quando uma tabela do banco é definida para cada coluna da tabela deve ser especificado um
conjunto de valores possível, isto chamamos de domínio do atributo.
Além disso, deve ser especificado se esta coluna poderá ficar “vazia” ou “nula”.
Normalmente todas as colunas que compõem a chave primária deve ser preenchidas para as demais
chaves não existe esta restrição.
RESTRIÇÕES DE INTEGRIDADE
Um dos objetivos primordiais de um SGBD é a integridade dos dados. Ao dizermos que as
informações/dados de um banco de dados são integras, significa dizer que elas refletem corretamente a
realidade apresentada pelo banco de dados e que são consistentes entre si.
Para tentar garantir esta integridade de um banco de dados os SGBD oferecem o mecanismo
de restrições de integridade.
- Integridade de domínio: Especificam que o valor de um campo deve obedecer a definição
de valores admitidos para a coluna (domínio da coluna ou do atributo). Nos SGBD é possível definir apenas
domínios pré-definidos. Exemplos: Datas, números inteiros, alfanumérico de tamanho definido, etc.... Não é
possível o usuário definir valores próprios de sua aplicação, tais como: Unidade da federação.
- Integridade de vazio: Especificar se o conteúdo de determinada coluna pode estar vazio ou
deve obrigatoriamente ser preenchido.
- Integridade de chave: Trata-se da restrição que define que os valores da chave primária e
alternativa ou alternada devem ser únicos.
- Integridade referencial: É a restrição que define que os valores dos que apareçam em uma
chave estrangeira devem aparecer na chave primária da tabela referenciada.
TRANSFORMAÇÕES ENTRE MODELOS
Dispomos de duas formas de modelagem; Modelagem ER e Modelagem Relacional.
Estas modelagens trabalham com os dados em níveis de abstração diferentes; a primeira modela os
dados de forma independente do SGBD no qual serão implementados e a nível conceitual, já a segunda
realiza a modelagem junto ao SGBD, que será utilizado e a nível lógico.
Projeto Lógico: Transformação (implementação) do modelo ER em modelo relacional.
Engenharia Reversa: É o contrário da primeira, é a transformação de um modelo lógico em modelo
ER (obter um diagrama ER, a partir de um SGBD, já implementado).
TRANSFORMAÇAO DE UM MODELO DER PARA RELACIONAL
Existem algumas regras para realizar esta transformação, esta regras foram definidas tendo em vista
basicamente dois pressupostos básicos:
São três basicamente as etapas necessárias para transformamos um modelo DER em um modelo
lógico (relacional): Tradução de entidades e respectivos atributos, tradução de relacionamentos e respectivos
atributos e tradução de generalizações e especializações.
1.) Tradução de entidades e respectivos atributos. Cada entidade é traduzida para uma tabela, onde
cada atributo será uma coluna desta tabela.
Os atributos identificadores correspondem às colunas que compõem a chave primária da tabela.
Exemplo: Tabela Aluno. Alunos (Matricula, Nome, Endreço, Telefone, DataNasc, Sexo,)
1.1.) Nome de atributos e nomes de colunas.
Não é aconselhável simplesmente transcrever os
nomes dos atributos para os nomes de colunas. Devemos procurar criar padrões de nomes de colunas em um
SGBD.
1.2.) Relacionamento Identificador.
Podem existir situações que não é trivial, quando acontece
de uma entidade ter um relacionamento identificador. Exemplo: Entidade dependente de funcionário em um
sistema de folha de pagamento.
Para um dependente ser identificado pelo sistema ele necessita estar vinculado ao
funcionário do qual ele é dependente e ainda ter um atributo que o identifique entre os demais
dependentes deste funcionário.
Existe uma regra de tradução para estes casos, que indica que devemos ter uma coluna na tabela para
cada identificador externo (identificador do funcionário). Esta coluna deverá fazer parte da chave primária da
tabela, no exemplo, fará parte da chave primária da tabela dependente.
Uma tabela que possui identificadores externos em sua chave primária, é possível ter identificador
externo de diversas tabelas.
Exemplo: Dependentes de um empregado, que faz parte uma empresa com diversas filiais. Teremos
uma chave primária composta de diversos atributos, inclusive de outras entidades (mais de uma).
Unidade (CodUnid, Nome, Localização)
Empregado (CodUnid, Matricula, Nome, DataAdm, Salário, Função)
Dependente (CodUnid, Matricula, CodDep, Nome, Vinculo, Sexo, DataNas)
2.) Tradução de relacionamento e respectivos atributos.
O fator determinante para a tradução (implantação) de relacionamentos é o da cardinalidade mínima
e máxima entre as entidades, que compõem o relacionamento.
2.1.) Existem três formas básicas de tradução de relacionamentos, que são as seguintes:
2.1.1.) Tabela própria.
O relacionamento é implementado através de uma tabela, que contem o seguinte:
Colunas com os atributos que identificam as entidades que participam do relacionamento.
Colunas com os demais atributos do relacionamento (atributos inerentes ao relacionamento).
A chave primária desta tabela é o conjunto das colunas que identificam as entidades que participam
do relacionamento. Os atributos que formam estas colunas, devem ser chaves primárias em suas respectivas
tabelas, e serão chaves estrangeiras nos relacionamentos.
Exemplo: Aluno e Disciplina.
Tabela Aluno. Alunos (Matricula, Nome, Endreço, Telefone, DataNasc, Sexo,)
Tabela Disciplina. Disciplinas (CodDisc, Nome, Créditos, Semestre)
Tabela Cursa. Cursa (Matricula, CodDisc, Notas, Freqüência, Resultado, Observações)
2.1.2.) Colunas adicionais dentro da tabela de entidades.
Outra alternativa de implementação de relacionamentos é a inserção de colunas em uma
tabela correspondente a uma das entidades que participam do relacionamento.
Entretanto isto somente é possível quando uma das entidades (tabelas) que participa do
relacionamento tem cardinalidade máxima um.
Para isto devemos inserir na tabela mestre (podemos assim chamar) as colunas que
identificam a segunda tabela. Estas colunas serão chaves estrangeiras na tabela “ mestre” e chave
primária na outra tabela.
Exemplo: Relacionamento Produto X Grupo.
Tabela Grupos. Grupo (CodGru, Nome, Observações)
Tabela Produtos. Produtos (CodBarr, Descrição, Unidade, Pvenda, Qestoq, CodGru)
2.1.3.) Fusão de tabelas de entidades.
Esta forma prevê a fusão das tabelas envolvidas no relacionamento. Entretanto isto somente
pode ser aplicado quando o relacionamento é de (1:1).
Exemplo: Relacionamento de um casamento (sendo único para toda a vida), sem
possibilidade de separação. Marido X Esposa.
Tabela Casamento. Casamento (Certidão, CIMar, CIEsp, Data, Local, Regime)
2.2.) Detalhes da implementação de relacionamentos.
A cardinalidade de um relacionamento determina, como deve ser a sua implementação.
Tipos de Relacionamento
Tabela Própria
Regras para implementação
Adição de Coluna
Fusão de Tabelas
2.2.1.1 (0,1)
2.2.1.2 (0,1)
2.2.1.3 (1,1)
(0,1)
(1,1)
(1,1)
2.2.2 (0,1)
2.2.2 (0,1)
2.2.2 (1,1)
2.2.2 (1,1)
(0,N)
(1,N)
(0,N)
(1,N)
2.2.3 (0,N)
2.2.3 (0,N)
2.2.3 (1,N)
(0,N)
(1,N)
(1,N)
Relacionamentos (1:1)
Pode ser usada
Preferir
Não usar
Pode ser usada
Não usar
Pode ser usada
Relacionamentos (1:N)
Pode ser usada
Preferir
Pode ser usada
Preferir
Não usar
Preferir
Não usar
Preferir
Relacionamentos (N:N)
Preferir
Não usar
Preferir
Não usar
Preferir
Não usar
Não usar
Preferir
Preferir
Não usar
Não usar
Não usar
Não usar
Não usar
Não usar
Não usar
Estas regras visam evitar junções e diminuir o número de chaves primárias.
2.2.1.) Relacionamentos (1:1).
2.2.1.1.) Quando ambas as entidades tem participação opcional.
Entidade Homem com os seguintes atributos: Identidade e nome.
Entidade Mulher com os seguintes atributos: Identidade e nome.
Para modelar a união (casamento) entre homem e mulher, sendo que casamento deve carregar os
atributos data, local e regime de comunhão de bens.
A melhor alternativa é a adição de colunas (com os atributos de casamento) a uma das entidades
(Homem ou mulher). A implementação seria expressa da seguinte forma:
Mulher (IdentM, Nome, IdentH, Data, Regime, Local)
IdentH referencia Homem
Homem (IdentH, Nome)
Outra alternativa seria gera uma tabela própria para casamento, expressa da seguinte forma:
Homem (IdentH, Nome)
Mulher (IdentM, Nome)
Casamento (IdentM, IdentH, Data, Regime, Local)
IdentH referencia Homem
IdentM referencia Mulher
A desvantagem da primeira opção é a existência de atributos, que podem ser nulos na entidade
Mulher, caso esta não seja casada. Esta é uma restrição que geralmente não é controlada pelo banco de
dados, ficando sob a responsabilidade do desenvolvedor.
2.2.1.2.) Quando uma entidade tem participação opcional e outra tem participação
obrigatória.
Entidade Correntista com os seguintes atributos: Identidade e nome.
Entidade Empréstimo com os seguintes atributos: Número, valor, vencimento e pagamento.
A melhor alternativa é a fusão de tabelas, que seria expressa da seguinte forma:
Correntista (Identidade, Nome, NroEmprest, valor, vencimento, pagamento)
A segunda alternativa seria a adição de colunas à tabela que pode ter cardinalidade mínima (zero).
Correntista (IdentCor, Nome)
Empréstimo (Número, valor, vencimento, pagamento, IdentCor)
IdentCor referencia Correntista
2.2.1.3.) Quando ambas as entidades tem participação obrigatória.
Entidade Comissão Organizadora com os seguintes atributos: Nome e endereço.
Entidade Conferência com os seguintes atributos: Código, data e assunto.
A melhor alternativa é a fusão de tabelas, que seria expressa da seguinte forma:
Conferência (Código, data, assunto, NomeComis, EnderComis)
2.2.2.) Relacionamentos (1:N).
Nesta situação a alternativa preferia é a adição de colunas.
A implementação com tabela própria tem duas desvantagens em relação à implementação por adição
de colunas, que são as seguintes:
- Favorecem a formação de junções em rotinas de pesquisas (consultas, relatórios e outras)
- Podem favorecer o surgimento de chaves primárias iguais.
Exemplos:
01.) Entidade Edifício, com os seguintes atributos: Código, nome e endereço
Entidade Apartamento, com os seguintes atributos: Número, proprietário e área construida.
A melhor alternativa é a adição de colunas, que seria expressa da seguinte forma:
Edifício (CodEdif, Nome, Endereço)
Apartamento (NroApt, CodEdif, proprietário, area)
CodEdif referencia Edifício
02.) Entidade Financeira, com os seguintes atributos: Código e nome.
Entidade venda, com os seguintes atributos: Número, data, valor, parcelas e juros.
A melhor alternativa é a adição de colunas, que seria expressa da seguinte forma:
Financeira (CodFinan, Nome)
Vendas (NroVenda, data, valor, parcelas, juros, CodFinan)
CodFinan referencia Financeira
A alternativa através de tabela própria seria expressa da seguinte forma:
Financeira (CodFinan, Nome)
Vendas (NroVenda, data, valor, parcelas, juros)
Financiamento (NroVenda, CodFinan)
NroVenda referencia Vendas
CodFinan referencia Financeira
* Aparecem duas chaves primárias iguais.
2.2.3.) Relacionamentos (N:N).
Nesta situação a alternativa preferia é a adoção de uma tabela própria, pois uma entidade pode estar
associada a diversas outras, desta forma fica inviável a adição de tabelas ou fusão de colunas.
Exemplo: Relação entre aluno e disciplina.
Disciplina (CódDisc, nome, créditos,)
Aluno (MatAlu, nome)
Cursa (MatAlu, CodDisc, semestre)
MatAlu referencia Aluno
CodDisc referencia Disciplina
2.3.) Relacionamentos com mais de duas entidades.
As regras até aqui apresentadas, aplicam-se somente a relacionamentos com duas entidades
(relacionamentos binários). Para relacionamentos com mais de duas entidades, devemos aplicar a
seguintes regra:
- O relacionamento é transformado em uma entidade, que é ligada através de um
relacionamento binário a cada uma das entidades que participavam do relacionamento original.
Exemplo:
Entidade cidade, com os seguintes atributos: Código e nome.
Entidade produto, com os seguintes atributos: Código, nome e preço venda.
Entidade distribuidor, com os seguintes atributos: Identidade e nome.
Cidade (CódCida, nome)
Produto (CodProd. Nome, pvenda)
Distribuidor (IdentDis, nome)
Distribuição (CodProd, IdentDist, CodCida, quantidade)
CodProd referencia produto
IdentDist referencia distribuidor
CodCida referencia cidade
2.4.) Implementação de generalização e especialização.
Existem duas opções para a implementação de generalização/especialização:
2.4.1.) Uma tabela por hierarquia:
Todas as tabelas referentes às especializações de uma entidade genérica são fundidas em uma única
tabela. Que será composta de:
- Chave primária correspondente ao identificador da entidade genérica.
- Caso não exista, devemos criar uma coluna Tipo, que identifique que tipo de entidade especializada
está sendo representada por cada linha da tabela.
- Uma coluna para cada atributo da entidade genérica.
- Colunas referentes aos relacionamentos dos quais participa a entidade genérica e que sejam
implementados através da alternativa de adicionar colunas à tabela da entidade genérica.
- Uma coluna para cada atributo de cada entidade especializada (estas colunas devem ser definidas
como opcionais, já que somente serão preenchidas quando a linha for referente a entidade especializada).
- Colunas referentes aos relacionamentos dos quais participa cada entidade especializada e que sejam
implementados através da alternativa de adicionar colunas à tabela da entidade (estas colunas devem ser
definidas como opcionais, já que somente serão preenchidas quando a linha for referente a entidade
especializada).
Exemplo: Empregado (entidade genérica) que está lotado em um departamento e que pode ter as
especializações:
Secretária: Que deve especificar que língua domina.
Motorista: Que deve conter a carteira de habilitação.
Engenheiro: Que deve ter o ramo da engenharia e de quais projetos participa.
Tabela Empregado, além de suas especializações, contém as seguintes colunas:
- CodEmp, chave primária da tabela.
- Colunas nome, CPF, CI e tipo referente a entidade especializada.
- Coluna CodDepto, que relaciona com o departamento (relacionamento lotação).
- Coluna Carthabil que compõem (implementa) a entidade especializada motorista.
- Coluna CREA, que compõem (implementa) a entidade especializada engenheiro.
- Coluna CodRamo, que implementa o relacionamento entre Engenheiro e o ramo da engenharia.
- Relacionamento particicpa, que informa de qual o projeto participa o engenheiro.
Pelas regras apresentadas no item 2.2, os relacionamentos (lotação e participa) são implementados
com tabela própria.
A entidade secretária não gera nenhuma coluna, visto que não possui atributos nem participa de
relacionamentos que gerem colunas.
Esquema relacional para a implementação:
Empregado (CodEmp, nome, cpf, ci, tipo, CodDepto, CartHabil, CREA, CodRamo)
CodDepto referencia Departamento
CodRamo referencia Ramo
Departamento (CodDepto, nome)
Ramo (CodRamo, nome)
Processador (CodProc, nome)
Domínio (CodEmp, Codproc)
CodProc referencia Processador
CodEmp referencia Empregado
Projeto (CodProj, nome)
Participa (CodEmp, CodProj)
CodEmp referencia Empregado
Codproj referencia Projeto
2.4.2.) Uma tabela por Entidade Especializada:
Uma segunda possibilidade é criarmos uma tabela para cada entidade que compõem a hierarquia.
Devemos incluir nas entidades especializadas o atributo correspondente a chave primária da tabela
genérica.
Utilizando-se do exemplo anterior, a implementação seria da seguinte forma:
Criamos uma tabela para a entidade Empregado e cada uma de suas especializações. Todas tem a
mesma chave primária. Na tabela empregado temos todas as informações referentes ao empregado. As
informações em particular de cada empregado (motorista e engenheiro), estarão em tabelas próprias
conforme o tipo.
Esquema relacional para a implementação:
Empregado (CodEmp, nome, cpf, ci, tipo, CodDepto)
CodDepto referencia Departamento
Motorista (CodEmp, CartHabil, Vencto)
CodEmp referencia Empregado
Engenheiro (CodEmp, CREA, CodRamo)
CodEmp referencia Empregado
CodRamo referencia Ramo
Departamento (CodDepto, nome)
Ramo (CodRamo, nome)
Processador (CodProc, nome)
Domínio (CodEmp, Codproc)
CodProc referencia Processador
CodEmp referencia Empregado
Projeto (CodProj, nome)
Participa (CodEmp, CodProj)
CodEmp referencia Empregado
Codproj referencia Projeto
REFINAMENTO DO MODELO RELACIONAL
Em todo o processo existe um compromisso entre o ideal e o que é possível realizarmos dentro de
determinadas circunstâncias. Na implementação de um banco de dados, também é necessário termos esta
relação/comparação. Existem as regras de implemtanção até aqui apresentadas, que devem ser
consideradas sempre que possível e respeitadas integralmente, a menos que seja extremamente importante
por uma questão de performance do banco (s0ftware) implementarmos soluções que violem as mesmas.
Existem algumas situações nas quais podemos “violentar” as regras até aqui apresentadas:
01.) Relacionamento mutuamente exclusivo. Acontece quando uma entidade participa de
forma mutuamente exclusiva de um ou outro relacionamento.
02.) Atributos Multivalorados (Simular). Acontece quando uma entidade necessita de
atributos multivalorados, estes podem ser limitados. Estes atributos jamais sofrerão uma indexação/seleção
em pesquisas.
03.) Informações Redundantes. Informações redundantes são aquelas que podem ser obtidas
através de outras informações da mesma entidade ou de outras entidades existentes no banco. As regras de
implementação não recomendam a criação de atributos para estas informações, mas em alguns casos é
conveniente criarmos um atributo para armazenar estas informações.
ENGENHARIA REVERSA - NORMALIZAÇÃO
Dependência funcional:
Entende-se por dependência funcional, quando uma coluna (de uma tabela), depende funcionalmente
de outra coluna da mesma tabela (que faz parte da chave primária). Outra forma de expressarmos
conceitualmente dependência funcional é dizermos que sempre que uma coluna X, apresentar um valor,
obrigatoriamente outra(s) coluna(s), terão tambem um valor constante, ou seja, a coluna X determina o valor
das outras.
Dependência transitiva:
Entende-se por dependência funcional, quando uma coluna (de uma tabela), depende funcionalmente
de outra coluna da mesma tabela (que não faz parte da chave primária). Outra forma de expressarmos esta
dependência é dizermos que sempre que uma coluna X, apresentar um valor, obrigatoriamente outra(s)
coluna(s), terão tambem um valor constante, ou seja, a coluna X determina o valor das outras.
Dependência funcional multivalorada:
Entende-se por dependência funcional multivalorada, quando uma coluna (de uma tabela), depende
multivaloradamente de outras.
Procedimentos para a normalização:
Existem quatro regras para que possamos completar o processo de normalização, são as chamadas 4
regras normais.
Antes de aplicarmos estas regras normais, devemos desenvolver o esquema relacional. Descreve-se
as informações, como uma entidade única. Representa-se todas as informações como se fossemos
implementar um a entidade em um banco de dados relacional.
Vamos trabalhar com os dados de um pedido de compra, com os seguintes dados:
EMPRESA DE VENDAS X-Y
Pedido Número: 987654
Data Pedido: 02/06/2002
Data Entrega: 15/06/2002
Cliente: 101.882.851-23 Urcamp-Livramento
Endereço: Estrada da educação, 987 Km 125.
Cidade: Livramento
Bairro: Palomas
Cep: 96400-900
Unid.Federação: RS
Código
Descrição
Quantidade
Valor Unitário
Valor Total
1234
Caixa de Giz
1500
1,50
1.500,00
9876
Apagadores
200
2,00
400,00
9632
Canetas
300
0,50
150,00
Total Geral
2.050,00
01.) Primeira formal normal.
Uma tabela/entidade está na primeira formal normal quando ela não contém tabelas aninhadas.
Devemos construir uma tabela para cada tabela (dados) aninhados.
Nesta etapa já devemos selecionar, ou indicar, as chaves primárias e manter a vinculação (ligação)
entre as tabelas, no caso na tabela produtos vincular o número do pedido.
02.) Segunda formal normal.
Devemos compreender o conceito de dependência funcional (ou parcial – de parte da chave
primária), para realizarmos esta regra.
2.1.) Copiar para a segunda forma normal, toda tabela que contenha apenas uma chave primária
simples ou que não contenha colunas além da chave primária.
2.2.) Para as tabelas com chaves primárias compostas e com outras colunas não chaves.
- Para cada coluna não chave, verificar a sua dependência funcional, ou seja, verificar se ela depende
de todas a chave primária ou apenas de parte dela.
- Criar tabelas, conforme a dependência da coluna.
03.) Terceira formal normal.
Devemos compreender o conceito de dependência transitiva para realizarmos esta regra.
Nesta regra devemos eliminar as dependências transitivas, criando tabelas conforme a necessidade.
04.) Quarta forma normal.
Eliminar as dependências funcionais multivaloradas.
Problemas da Normalização:
- Chaves primárias omitidas ou incorretas;
- Atributos relevantes implicitamente representados.
- Atributos redundantes;