Você está na página 1de 31

Conceitos básicos

1
NECESSIDADE DAS BASE DE DADOS
Permite guardar dados dos mais variados tipos;
Permite um rápido e fácil acesso aos dados;

Acelera os processos de manuseamento da informação, como,


por exemplo, consultas ou alterações de dados;

Economiza toneladas de papel.

2
TABELAS, REGISTOS E CAMPOS
Um objecto fundamental quando estamos perante um sistema
informático é uma Tabela.
Uma Tabela encontra-se estruturada em linhas e colunas. As linhas
são designadas por Registos e as colunas por Campos.
Cada um dos registos (linhas) contém apenas os dados de um
elemento, organizados em campos (colunas).

3
TABELAS, REGISTOS E CAMPOS
Uma estrutura deste género facilita eventuais alterações aos dados da
lista de contactos, já que, para cada pessoa, todos os dados estão inseridos
na mesma linha.

Todas as operações de manutenção dos dados de uma Tabela são


realizadas individualmente para cada um dos Registos. Isto é, se for
necessário alterar algum dado num determinado contacto (pessoa),
acedemos directamente ao Registo em causa e efectuamos essa alteração no
respectivo Campo.

4
FICHEIRO DE BASE DE DADOS (ÚNICO FICHEIRO VS
COLECÇÃO DE FICHEIROS)

Único ficheiro físico, como é o caso de uma base de dados em Access;


Colecção de ficheiros físicos geridos por um SGBD, como é o caso de outras
aplicações de base de dados.

Independentemente da base de dados ser um único ficheiro ou uma colecção de


ficheiros físicos, os objectos são todos tratados da mesma forma.
Normalmente, quando estamos a usar o Access como SGBD, e como se trata de um
único ficheiro físico, é comum designarmos esse ficheiro por “documento” do Microsoft
Access.

5
DADOS E INFORMAÇÃO

Dados = Informação

Dados
Os Dados são os elementos isolados, significativos, rigorosos e relevantes.
Podem ser vistos como a matéria-prima necessária para um determinado
processamento.

Informação
Podemos entender Informação como um conjunto de dados, organizados e
sujeitos a um tratamento, tornando assim possível a sua utilização num
determinado contexto. Os dados não têm qualquer valor e só se transformam
em informação quando relacionados.
6
DADOS E INFORMAÇÃO

EXEMPLO

A frase: “O João comprou 2 canetas” é informação.


Os dados que permitiram criar essa informação são:
“João”, “comprou”, “2” e “canetas”.

7
DADOS E INFORMAÇÃO

Uma informação actual e correcta só é possível se os seus dados


estiverem actualizados e forem precisos. De outra forma, a nossa
informação não será útil. Mas, para que isto possa acontecer, existem
algumas condições que os dados devem garantir:

Actualidade;
Correcção;
Relevância;
Disponibilidade;
Legibilidade.

8
SISTEMAS DE GESTÃO DE BASE DE DADOS
(SGBD)
Software que disponibiliza todos os serviços básicos, como a criação, o
acesso e a manutenção da informação numa base de dados.

As base de dados são um conjunto de dados estruturados e manipulados


através de um SGBD.

Capacidade de processar grandes quantidades de informação, tais como:


 Sistemas de armazenamento de operações bancárias;
 Base de dados empresariais com vários tipos de informação
(ex.: vendas, funcionários, clientes, fornecedores, facturação);
 Sistemas de reservas de companhias de aviação;
 Sistemas de companhias de seguros.

9
EXEMPLOS DE SGBD

Dividem-se em dois grandes grupos:

 Grande porte
Exemplos: ORACLE, Microsoft SQL Server, Ingres, Informix e DB2;

 Uso pessoal (doméstico) e ou de pequenas empresas.

Exemplos: MySQL, Dbase, FoxPro e o Microsoft Access.

10
Características de um SGBD

Independência dos dados;


Redundância controlada;
Integridade dos dados;
Abstracção dos dados; Acesso
simultâneo aos dados;
Facilidade de obtenção de informação actualizada;
Diferentes vistas da base de dados.

11
CAMADAS DE ABSTRACÇÃO

Um SGBD permite que cada utilizador tenha uma vista diferente


(abstracta) do conteúdo da base de dados;

Cada utilizador necessita de ter acesso a diferentes perspectivas da


base de dados (exemplo: Director Comercial, Dep. Compras);

As estruturas de dados contêm um certo nível de complexidade,


podendo não ser bem entendidas pelos utilizadores menos habilitados;

Como as vistas não arquivam nenhum dado, reflectem


automaticamente qualquer mudança efectuada na camada básica dos
dados. Isto é possível devido à abstracção das camadas.

12
DEFINIÇÃO DE BASE DE DADOS
Sistema de armazenamento de dados relacionados entre si, de
uma forma permanente, num sistema informático, com
redundância controlada, acessíveis a um grupo de utilizadores
e estruturado sob a forma de ficheiros de dados ou tabelas.

Podemos entender dados como factos conhecidos que podem ser


armazenados e que possuem um significado implícito;

Uma base de dados é uma colecção lógica e coerente de dados, com


um significado inerente;

Uma base de dados é planeada, construída e actualizada com dados que


representam aspectos do mundo real, como se de um “pequeno mundo” se
tratasse.
13
CICLO DE VIDA DE UMA BASE DE DADOS

Este modelo do ciclo de vida de


uma base de dados é constituído
por 8 fases;
Apenas podemos passar para a
fase seguinte depois da anterior
estar concluída;
Por vezes, surge a necessidade
de retroceder à fase anterior, para
realizar determinados ajustes.

14
CICLO DE VIDA DE UMA BASE DE DADOS
 1. Planeamento
Levantamento das necessidades, organizar e planear.

 2. Recolha de requisitos
Elaboração de um documento com os objectivos que o projecto visa atingir.

 3. Desenho conceptual
Desenho de todos os modos de vista externos da aplicação e da base de
dados. O aspecto dos formulários, relatórios, ecrãs de entrada de dados, etc.

 4. Desenho lógico
A partir do desenho conceptual cria-se o desenho lógico da aplicação
e da base de dados.

15
CICLO DE VIDA DE UMA BASE DE DADOS
 5. Desenho físico
Durante a fase de desenho físico, o desenho lógico é mapeado ou
convertido
para os sistemas de software que serão usados na implementação da
aplicação e da base de dados.

 6. Construção
As unidades de programação são promovidas para um sistema de
ambiente de teste,
onde toda a aplicação e base de dados é montada e testada.

 7. Implementação
Instalação e colocação em funcionamento da nova aplicação e base
de dados.
16
MODELOS DE BASE DE DADOS

 Conjunto de conceitos que podem ser utilizados para


descrever e representar a estrutura lógica e física da base
de dados;

 A estrutura de uma base de dados pode ser entendida como


toda a descrição dos dados, dos relacionamentos entre eles
e das restrições de consistência e integridade;

 Estes modelos encontram-se divididos em dois grupos, os


modelos conceptuais (ou baseados em objectos) e os
modelos de implementação (ou baseados em registos).

17
MODELOS DE BASE DE DADOS

Modelo conceptual de dados


 Fundamental para o desenvolvimento de qualquer base de dados;
 É apenas um modelo lógico, o que traduz a abstracção da realidade;
 Fornece uma visão aproximada de como os utilizadores realmente visualizam
os dados;
 Converte-se posteriormente num dos modelos de implementação de
base de dados existentes.

Modelos de implementação
 Permitem descrever a forma como os dados estão representados num
SGBD;
 O Modelo Relacional, desenvolvido em 1970, é o mais popular e será
estudado mais em pormenor.
18
19
O Modelo Relacional de base de dados é actualmente o modelo de implementação mais
utilizado. Este sucesso pode ser explicado pela sua simplicidade e grande capacidade de resposta
às necessidades dos utilizadores;

Este modelo afirmou-se perante os outros devido à sua forte base teórica em Álgebra Relacional;

O Modelo Relacional é constituído somente por relações, onde cada relação é uma tabela.

Quando uma relação é pensada como uma tabela de valores, cada linha nesta tabela
representa uma colecção de dados relacionados;

Estes valores podem ser interpretados como factos descrevendo uma instância de uma
entidade ou de um relacionamento;

Hoje em dia, o Modelo Relacional é a base de trabalho de qualquer Sistema de Gestão de Base
de Dados Relacional (SGBDR). A sua simplicidade, bem como a separação entre a definição e a
manipulação dos dados, foram factores importantes para o seu sucesso.
20
RELAÇÃO, TUPLO E ATRIBUTO

Uma Relação é uma estrutura fundamental do modelo relacional, bidimensional, representada


por uma tabela organizada em linhas e colunas, respectivamente Tuplos e Atributos. Ou seja, um
Atributo é uma coluna à qual atribuímos um nome, e um Tuplo é uma linha de uma relação (ou
instância da relação). O tipo de dados que descreve cada coluna designa-se domínio.

No modelo relacional, as relações ou tabelas são utilizadas para guardar dados dos objectos
que queremos representar na base de dados. O nome da tabela e das colunas é utilizado para
facilitar a interpretação dos valores armazenados em cada linha da tabela. Todos os valores de uma
coluna são, necessariamente, do mesmo tipo.

A ordem dos tuplos ou dos atributos pode variar. Os tuplos poderão aparecer segundo
qualquer ordem, que continuaram a ter a mesma relação e o mesmo significado. O mesmo acontece
com os atributos: independentemente da ordem que apresentam, os atributos têm um nome que
traduz o tipo de dados a armazenar.
21
DOMÍNIO DE UM ATRIBUTO

Os atributos traduzem o tipo de dados a armazenar. A cada atributo está associado um


domínio ou gama de valores possíveis que este pode ter. Isto é, o domínio de um atributo é o
conjunto de valores permitidos para esse atributo. Por exemplo, um atributo “notas”: as notas
(ou classificações) dos alunos podem ir de 0 (zero) a 20 (vinte) valores; então, o domínio do
atributo será todos os valores compreendidos entre estes dois números.

O conceito de domínio é importante, pois permite que seja definido o significado e a fonte
dos valores para cada um dos atributos, podendo assim evitar-se operações incorrectas nas
relações.

Quando definido o significado e a fonte dos valores para cada um dos atributos, deve ser
assegurado que o domínio de um atributo é constituído por valores atómicos, isto é, os
valores que ele vai poder assumir são indivisíveis.

22
GRAU E CARDINALIDADE DE UMA RELAÇÃO
O grau de uma relação é o número de atributos (ou campos) dessa relação. A cardinalidade
da relação é o seu número de tuplos (ou registos).

Enquanto que o grau de uma relação tem, normalmente, um valor fixo, a cardinalidade de uma
relação muda frequentemente. Isto é, à medida que novos tuplos são adicionados ou removidos,
a cardinalidade é alterada. O grau de uma relação só é alterado quando o significado da
relação é intencionalmente modificado para incluir novos atributos.

Uma base de dados relacional é o conjunto das relações associadas, apropriadamente


estruturadas, ou seja, um conjunto de relações normalizadas.

23
NOME DE UMA RELAÇÃO

Existem algumas convenções para a utilização dos nomes, quer para as relações (tabelas),
quer para os atributos que a constituem.

Uma convenção não tem sentido obrigatório; no entanto, deve ser respeitada, para evitar
incompatibilidades ou erros.

Determinados SGBD, como é o caso do Microsoft Access, permitem algum tipo de flexibilidade ao
nível dos nomes das tabelas e dos nomes dos atributos, ao contrário de outros.

Este tipo de flexibilidade pode trazer inconvenientes quando pretendemos fazer a migração
de um SGBD em Access, por exemplo, para um SGBD em Oracle.

O Oracle é um SGBD menos flexível no que diz respeito ao nome das tabelas e ao nome dos
atributos.

24
NOME DE UMA RELAÇÃO

Convenção dos nomes das relações ou tabelas:

Os nomes das tabelas deverão ter por base as entidades que representam.

O nome da cada tabela deve ser único, ou seja, não deve haver duplicação de
nomes de tabelas dentro da mesma base de dados.

Existem diferentes convenções quanto à singularidade ou pluralidade dos nomes das


tabelas. Alguns utilizadores preferem utilizar nomes no singular enquanto que outros
preferem nomes no plural. Não é importante a convenção adoptada; é sim importante
manter a coerência do método adoptado em todas as tabelas, isto é, se se optar por um
nome no singular dever-se-á utilizar nomes no singular em todas as tabelas e vice-versa.

25
NOME DE UMA RELAÇÃO

Convenção dos nomes das relações ou tabelas:

Não incluir palavras como “tabela” ou “ficheiro” nos nomes das tabelas.

Alguns SGBD podem ser sensíveis ao facto do nome da tabela estar escrito
em maiúsculas e/ou minúsculas. Nestes casos, para evitar erros de escrita,
devemos optar por escrever o nome da tabela todo em maiúsculas ou todo em
minúsculas. Por convenção, para os nomes, devemos utilizar unicamente
letras maiúsculas e o underscore (_) para separar palavras.

Usar abreviaturas quando necessário, por exemplo, para diminuir os nomes


que atinjam o número máximo de caracteres permitidos pelo SGBD.

26
NOME DE UM ATRIBUTO

Convenção dos nomes dos campos:

Os nomes dos campos devem basear-se no nome do atributo definido no


desenho lógico.

Os nomes dos campos devem ser únicos dentro da tabela.

Alguns SGBD podem ser sensíveis ao facto do nome do campo estar escrito em
maiúsculas e/ou minúsculas.

Por convenção, para os nomes dos campos devemos utilizar unicamente


letras maiúsculas e o underscore (_) para separar palavras.

27
ATRIBUTOS CHAVE

O conceito de chave é muito importante no modelo relacional. Para cada relação


deve existir uma chave, que vai ser constituída por um conjunto de um ou mais atributos,
que identifica cada tuplo (ou instância da relação) de um modo único, pois esta chave vai
permitir estabelecer o relacionamento com outras relações.

Não podem existir dois tuplos com os mesmos dados para o mesmo atributo
ou conjunto de atributos.

Quando uma chave é composta apenas por um atributo, podemos dizer que se
trata de uma chave simples. Uma chave constituída por mais do que um atributo é
denominada chave composta.

Para perceber melhor o que são as chaves e como funcionam no modelo


relacional, existem alguns conceitos que são necessários compreender, como é o
caso de chave candidata, chave primária e chave estrangeira.

28
ATRIBUTOS CHAVE

Chave candidata
Chaves candidatas são todos os conjuntos de um ou mais atributos possíveis para
identificar cada tuplo de um modo único. No entanto, para proceder a esta selecção de
chaves candidatas, é necessário conhecer bem a realidade de cada um dos
atributos da relação e qual o seu domínio.

Por exemplo, para a tabela Cliente, como chaves candidatas


podemos ter os atributos cod_cliente e nr_contribuinte.
29
ATRIBUTOS CHAVE

Chave primária
De entre todas as chaves candidatas apenas uma será escolhida para identificar cada tuplo
de forma única. A chave seleccionada de entre as chaves candidatas é designada chave primária
da relação.

Em todas as tabelas deve existir sempre uma chave primária e os atributos que a constituem
não podem conter valores nulos.

Por exemplo, para a tabela Cliente, como chave primária


seleccionaríamos o atributo “cod_cliente”.
30
ATRIBUTOS CHAVE

Chave estrangeira
Uma chave estrangeira é
um conjunto de um ou
mais atributos que são a
chave primária numa
outra relação.
Por exemplo, para a tabela Venda, a
sua chave primária é o conjunto de
Isto é, quando um atributo
dois atributos, cod_cliente e
surge em mais do que uma
cod_artigo.
relação, estamos perante
um relacionamento de No entanto, os elementos que
tuplos. constituem a chave primária da tabela
Venda, ambos, isoladamente, são
chaves estrangeiras. Isto é, ambos
existem como chaves primárias em
outras tabelas.
31

Você também pode gostar