Apostila Modelagem de Dados

Fazer download em pdf ou txt
Fazer download em pdf ou txt
Você está na página 1de 6

DISCIPLINA: Banco de Dados

SÉRIE: III TURMA: PROSUB


TEMA: Modelagem de dados TURNO: NOTURNO
ALUNA(O):
PROFESSOR (A): MARCOS ROGÉRIO

Desde a década de 1970, os bancos de dados existem como solução de repositório


de dados e informações. Eles garantem integridade, segurança, confiabilidade, etc.
Assim afirmarmos que a parte mais estável no tocante às tecnologias que envolvem
as soluções de TI está relacionada com os dados e com a forma em que eles são
armazenados e disponibilizados. A partir do entendimento do problema, uma boa
forma de propor uma solução é tomar como base a elaboração de um modelo de
persistência de dados com grande riqueza semântica.

 O dado é a origem da informação. Muitas das vezes não é possível, in-


dependentemente da tecnologia, alterar programas para obter uma in-
formação desejada. Ou seja, armazenando apenas o todo não é possível
conhecer as partes que o compõem.
 O dado é a infraestrutura do sistema e está por baixo da estrutura. Ele
suporta a estrutura. Portanto, mexer na forma de armazenar os dados
impacta toda a estrutura. O mesmo não é sempre verdade quando temos
mudança na regra de negócio contida nos programas ou na forma visual da
interface
 Normalmente, as falhas de normalização irão gerar esforço de programação
a fim de evitar inconsistência dos dados.
 Definir semântica no modelo de dados reduz a quantidade necessária de
código- fonte a ser escrito no programa aplicativo.

Modelo de dados ER(Entidade Relacionamento)

O modelo de dados é uma forma de abstração do mundo real. É um recorte no qual


criamos um “minimundo” do que se deseja representar. O modelo expressa para o
sistema a ser elaborado um entendimento de quais dados devem ser armazenados,
qual é a relação de dependência que existe entre eles e qual é o significado
semântico desses dados e de suas relações.
O modelo ou Diagrama de Entidade e Relacionamento (DER) é uma das formas
de abordagem semântica mais conhecida e provavelmente das mais utilizadas
atualmente. Ele foi proposto por Peter Chen em 1976, sendo, a partir daí, refinado e
ampliado por diversos autores. Um DER é composto por Entidades (tabela que
agrupam os dados de algo que se deseja armazenar no banco de dados). Ex.:
(Aluno, Curso) e Relacionamentos (representa a forma de como as entidades se
relacionam entre si). É importante destacar que as entidades são compostas de
atributos, os quais descrevem as características da própria entidade. (Ex.: nome do
aluno, número da matrícula do aluno, nome do curso, etc.).
Definindo Entidade
Uma entidade pode ser: um objeto com existên-
cia física (entidade concreta), ex.: um emprega-
do, um aluno, um carro; ou conceitual (entidade
abstrata), ex.: uma empresa, uma matrícula, um
relacionamento entre duas ou mais entidades.

Uma entidade pode ser descrita por


propriedades particulares que a distinguem e a descrevem. Essas propriedades são
chamadas de atributos da entidade. Fazendo associação às tabelas dos bancos de
dados, as linhas são as ocorrências e os atributos são as colunas da tabela.

Por exemplo: na entidade Piloto mostrada na figura ao lado, temos dois atributos
(colunas): Cod_Piloto, Nom_Piloto e três linhas nas quais é mostrado o conteúdo
para cada piloto cadastrado na tabela. Cada ocorrência ou linha da entidade possui
valores (atributos) que identificam um único piloto
.

Os atributos podem ser:

 Simples (atômicos) – quando não fizer sentido semântico dividir o atributo


em subpartes. Exemplo: a altura ou o peso de uma pessoa.
 Composto – quando o atributo puder ser dividido em subpartes com
significado semântico. Exemplo: endereço de uma pessoa pode ser dividido
em Cep, cidade, bairro, logradouro, número e complemento.
 Multivalorado – quando o atributo possuir simultaneamente mais de um
valor para uma mesma ocorrência da entidade. Exemplo: a cor de um carro
pode ser parte preta e parte branca.
 Derivado – quando o atributo puder ser calculado dinamicamente sem que
haja necessidade de manter o dado armazenado no banco de dados.
Exemplo: em uma entidade com itens de uma nota fiscal. A partir do preço
unitário e da quantidade vendida o valor total do item pode facilmente ser
calculado pela multiplicação dos dois termos. Obrigatório – quando não for
possível incluir uma linha na tabela sem que haja alguma informação/valor
nos atributos obrigatórios dela.
 Não obrigatório – quando ao inserir uma linha na tabela isto possa ser feito
independentemente da obrigação de informar dados aos atributos que
aceitam valores nulos.
 Complexo – quando juntamos os conceitos de atributos composto e
multivalorados.
 Delimitado – quando existir definição no banco de dados de uma regra de
domínio que delimite os valores válidos possíveis a serem armazenados.
Definindo Relacionamento

O relacionamento é uma representação da forma de como as entidades se re-


lacionam umas com as outras. Ele expressa certas restrições existentes no mini-
mundo a ser modelado que delimitam como uma ou mais ocorrências de uma
entidade se relacionam com uma ou mais ocorrências de outra entidade. Este
conceito é denominado cardinalidade do relacionamento. Para um conjunto de
relacionamento binário, entre duas tabelas T1 e T2, a cardinalidade pode ser:

Um para um – uma linha da tabela T1


está associada com no máximo uma
linha da tabela T2 e vice-versa.

Um para muitos – uma linha da tabela


T1 está associada com de zero a “n”
linhas da tabela T2, enquanto que, uma
linha da tabela T2 está associada com
no máximo uma linha da tabela
T1.Observe que relacionamentos
muitos para um é o inverso de um para
muitos.

Muitos para muitos – uma linha da


tabela T1 está associada com zero a
“n” linhas da tabela T2 e vice-versa.

Atributo chave (Candidata,Primária e Estrangeira)

Outra importante tarefa da modelagem é determinar dentre os atributos de uma


entidade/tabela quais são aqueles que de forma individual ou agrupada são capazes
de identificar uma única ocorrência da entidade. Esse conjunto de atributos é
chamado de chaves candidatas. Ou seja, são os possíveis candidatos a serem
definidos como chave primária. Entende-se como chave primária a menor
quantidade de atributos capaz de identificar uma ocorrência da tabela de forma
unívoca. Podem ocorrer casos em que tenhamos diversos conjuntos distintos de
chaves candidatas. Cabe ao projetista escolher dentre as possibilidades aquela que
for mais adequada como solução para o problema proposto.
É também possível que uma entidade não possua atributos suficientes para
formação de uma chave primária. Nesse caso poderá ser arbitrado um novo atributo
sem significado semântico, mas que sirva com chave ou parte da chave.
Normalmente uma sequência numérica serve como atributo complementar nas
entidades fracas, que herdam a chave da tabela pai, entidade forte.

Outro exemplo é o de uma entidade que não possui nenhum atributo natural capaz
de representar de forma unívoca uma linha da tabela. Nesse caso, a chave primária
pode ser definida como um atributo autoincrementado.

Um importante conceito é o de chave estrangeira. A chave estrangeira é utilizada


para ligar uma ocorrência de uma entidade a uma ou mais ocorrências de outra
entidade. Ela se caracteriza por aparecer em uma entidade com atributo originado
de outra entidade na qual ela é uma chave primária. Ou seja, a chave estrangeira é
uma referência numa entidade que aponta para a chave primária de outra entidade,
possibilitando dessa forma as junções entre as entidades envolvidas. É ela que
informa ao banco de dados a integridade referencial entre as tabelas envolvidas no
relacionamento.

Padronização

Na fase do projeto conceitual é importante definir nomes de tabelas e atributos se-


guindo alguma regra de padronização. Isto irá ajudar muito na organização e princi-
palmente no mapeamento do modelo conceitual para o esquema físico do banco de
dados, fazendo com que os ajustes da sua estrutura física sejam mínimos em rela-
ção ao projeto lógico.

Mas, afinal, qual deve ser o padrão? Na verdade, a resposta para esta pergunta é
que não existe uma regra única e obrigatória. Normalmente, cada grupo de desen-
volvedores dentro de uma empresa normatiza e escreve as suas próprias regras. A
seguir algumas sugestões de padronização.

Mesmo apesar de alguns SGBDs aceitarem características da língua portuguesa,


tais como: acentos, cedilha e espaços em branco. Essas situações devem ser
evitadas na criação de nomes de tabelas, atributos, etc. Agindo dessa forma você
estará evitando possíveis problemas de incompatibilidades. Além disso, um detalhe
importante é atentarmos para as limitações de nomenclatura do próprio SGBD que
será utilizado como repositório. Ao propor uma regra o importante é utilizar o bom
senso.
Nome de entidade/tabela

 Deve-se evitar uso de nomes codificados, como por exemplo, S01010, pois,
ao olharmos para o nome, ele não tem nenhum significado.
 Os nomes devem ter um limite de tamanho; normalmente 18 caracteres é o
máximo. Deve-se procurar utilizar nomes que traduzam de forma clara o sen-
tido da entidade, normalmente no singular. Exemplo: cliente, aluno, etc.
 Deve-se evitar vincular ao nome de uma tabela a associação a um deter-
minado sistema. Pode ocorrer que, em uma nova versão do sistema, a mes-
ma tabela passe a ser utilizada por dois ou mais sistemas. Nesse caso, seria
necessário trocar o seu nome, ou mantê-la no banco de dados com um nome
que não expressa a realidade. Exemplo: o sistema de contabilidade tem
um prefixo “contab”; então, usamos para nomear as tabelas este prefi-
xo: contab_plano_conta.
 Uma possível solução para reduzir o tamanho do nome é criar um mne-
mônico com um tamanho fixo de caracteres, por exemplo, seis caracteres,
sendo a formação do nome composta pelas iniciais do nome por extenso.
Exemplo: fornecedor = fornec; agência bancária = ageban, etc. Nesse
caso foi criada uma codificação, mas que mantém ainda assim certo te-
or semântico.

Nome de atributos
 Deve-se evitar uso de nomes codificados. Também se deve evitar usar o no-
me da tabela como parte do nome do atributo ex.: S01_Cod, Cliente_Cod,
Cliente_Nome.
 Os nomes devem ter um limite de tamanho; normalmente 18 caracteres é o
máximo.
 Deve-se dividir o nome do atributo em pelo menos duas partes. Um prefixo
identificador, para identificar o tipo do atributo, seguido de um underscore
(caracter de sublinhado) e uma sequência de caracteres para qualificar o
atributo. Veja o Quadro 1.1 com os identificadores sugeridos.
Atividade

1. Apresente pelo menos três vantagens dentro do ciclo de desenvolvimento de um


software que justifique o esforço na elaboração de um modelo de dados bem fei-
to?

2. Explique quais são as características dos atributos simples, compostos multivalo-


rados, derivados e obrigatórios.

3. Explique quais são os tipos possíveis de relacionamento.

4. Defina o que é uma chave candidata, chave primária e chave estrangeira.

5. Explique com exemplos quais são as boas práticas de padronização dos nomes
de tabelas e atributos.

Você também pode gostar