Você está na página 1de 64

FACULDADE DE TECNOLOGIA DE SO PAULO

Elisngela Rocha da Costa

BANCOS DE DADOS RELACIONAIS

So Paulo
2011

ELISNGELA ROCHA DA COSTA

Bancos de Dados Relacionais

Trabalho de Concluso de Curso


apresentado

Faculdade
de
Tecnologia de So Paulo, como
requisito parcial para a obteno do
grau
de
Tecnlogo
em
Processamento de Dados.
Orientador:
Bernice

So Paulo
2011

Prof.

Paulo

Roberto

AGRADECIMENTOS

Ao Prof. Bernice, meu orientador, pelo apoio na elaborao deste


trabalho.

RESUMO

Atualmente, obter informao rpida e confivel vital para a sociedade, sobretudo


para as organizaes. Bancos de dados possibilitam o controle e a disponibilizao
dessas informaes e por isso tornaram-se elementos indispensveis. Desta forma,
o presente trabalho se prope a abordar alguns dos principais tpicos dessa rea.
Todavia, dada a riqueza do tema e, consequentemente, sua extenso, focalizou-se
apenas os assuntos que dizem respeito a bancos de dados relacionais. Para tanto,
foi realizada uma pesquisa bibliogrfica em algumas obras de referncia. O texto a
seguir elaborado discute, entre outros, os conceitos de bancos de dados, sistemas
de banco de dados, modelagem semntica, modelo de dados, modelo relacional e
linguagem de consulta estruturada. Ao final, demonstra-se atravs de um estudo de
caso a importncia da abordagem de banco de dados. Ali, tambm fica ratificado
que a compreenso de assuntos concernentes ao campo de banco de dados
propicia o desenvolvimento de projetos de banco de dados mais eficientes.
Palavras-chave: bancos de dados, bancos de dados relacionais, armazenamento
de dados.

ABSTRACT
Currently, to obtain information quickly and reliably is vital to society, especially for
organizations. Databases allow the control and the availability of such information
and therefore have become indispensable elements. Thus, this study aims to
address some of the main topics in that area. However, given the richness of the
subject and, consequently, its length is only focused on the issues that relate to
relational databases. To this end, a literature search was performed in some
reference works. The following text discusses prepared, among others, the concepts
of databases, database systems, semantic modeling, data model, relational model
and structured query language. At the end, it is demonstrated through a case study
approach to the importance of the database. There is also ratified that understanding
of issues relevant to the field of the database enables the development of database
projects more efficient.
Keywords: databases, relational databases, data storage.

SUMRIO

1.

INTRODUO ............................................................................................... 7

2.

BANCOS DE DADOS .................................................................................... 8

2.1.

PORQUE UTILIZ-LOS ................................................................................. 8

3.

SISTEMA DE BANCO DE DADOS ............................................................. 10

3.1.

DADOS ........................................................................................................ 10

3.2.

HARDWARE ................................................................................................ 11

3.3.

SOFTWARE ................................................................................................. 11

3.4.

USURIOS .................................................................................................. 12

4.

ARQUITETURA DE SISTEMAS DE BANCO DE DADOS .......................... 13

4.1.

ESQUEMAS E INSTNCIAS ....................................................................... 13

4.2.

ARQUITETURA DE TRS ESQUEMAS ...................................................... 14

5.

CICLO DE VIDA E PROJETO DE BANCO DE DADOS ............................. 18

6.

O MODELO ENTIDADE-RELACIONAMENTO (E-R).................................. 20

6.1.

ENTIDADES E CONJUNTO DE ENTIDADES ............................................. 20

6.2.

ATRIBUTOS E DOMNIO DE VALORES ..................................................... 21

6.3.

RELACIONAMENTOS E CONJUNTOS DE RELACIONAMENTOS ............ 23

6.4.

AUTO-RELACIONAMENTOS ...................................................................... 25

6.5.

RESTRIES SOBRE TIPOS DE RELACIONAMENTO ............................ 25

6.5.1.

RAZO DE CARDINALIDADE OU CARDINALIDADE................................. 26

6.5.2.

RESTRIES DE PARTICIPAO E DEPENDNCIA DE EXISTNCIA .. 27

7.

O MODELO ENTIDADE-RELACIONAMENTO ESTENDIDO (EER)........... 29

7.1.

SUPERCLASSES, SUBCLASSES E HERANA DE ATRIBUTOS ............. 29

7.2.

ESPECIALIZAES E GENERALIZAES ............................................... 30

7.2.1.

RESTRIES DE ESPECIALIZAES E GENERALIZAES ................. 31

8.

O MODELO RELACIONAL ......................................................................... 33

8.1.

O ASPECTO ESTRUTURAL ....................................................................... 33

8.2.

O ASPECTO DE INTEGRIDADE ................................................................. 34

8.3.

O ASPECTO MANIPULATIVO ..................................................................... 37

9.

O PADRO-SQL ......................................................................................... 39

9.1.

LINGUAGEM DE DEFINIO DE DADOS.................................................. 39

9.1.1.

INSTRUO CREATE TABLE .................................................................... 40

9.1.1.1.

Domnios e tipos de dados ......................................40

9.1.1.2.

Restries de atributo, chave e integridade referencial


41

9.1.2.

INSTRUO DROP ..................................................................................... 44

9.1.3.

INSTRUO ALTER.................................................................................... 44

9.2.

LINGUAGEM DE MANIPULAO DE DADOS ........................................... 45

9.2.1.

INSTRUO SELECT ................................................................................. 45

9.2.1.1.

Clusulas select e from ..........................................45

9.2.1.2.

Clusula where .....................................................47

9.2.1.3.

Clusulas group by ................................................48

9.2.1.4.

Clusula having.....................................................49

9.2.1.5.

Clusula order by ..................................................50

9.2.2.

INSTRUO INSERT .................................................................................. 51

9.2.3.

INSTRUO DELETE ................................................................................. 51

9.2.4.

INSTRUO UPDATE................................................................................. 52

10.

ESTUDO DE CASO: MICROSOFT OFFICE ACCESS E O IFSP ............... 53

10.1.

UMA VISO GERAL DO ACCESS .............................................................. 54

10.1.1.

TABELAS .................................................................................................. 54

10.1.2.

CONSULTAS ............................................................................................ 55

10.1.3.

FORMULRIOS ........................................................................................ 57

10.1.4.

RELATRIOS ........................................................................................... 58

10.1.5.

MACROS .................................................................................................. 58

10.1.6.

MDULOS ................................................................................................ 58

10.2.

INSTITUTO FEDERAL DE SO PAULO ..................................................... 59

10.3.

IFSP E UTILIZAO DO ACCESS .............................................................. 59

11.

CONSIDERAES FINAIS ......................................................................... 62

12.

REFERNCIAS ........................................................................................... 63

1. INTRODUO

Os bancos de dados esto cada vez mais presentes em nosso dia-a-dia, visto que a
maioria das atividades que realizamos envolvem, direta ou indiretamente, o uso de
uma base de dados. Diante disso, apresentaremos nas sees seguintes uma
introduo aos conceitos fundamentais de banco de dados. Considerando que os
bancos de dados so em sua grande maioria ainda relacionais, esse trabalho os
enfatizar. Assim, o primeiro captulo conceitua banco de dados e tambm discute
as vantagens advindas dessa abordagem. O segundo captulo define sistema de
banco de dados, assim como discorre brevemente sobre cada elemento que o
compe. O terceiro captulo descreve abstrao e modelo de dados para ento
discorrer sobre a arquitetura para sistemas de banco de dados ANSI/SPARC. O
quarto captulo oferece uma viso geral das etapas de desenvolvimento de um
projeto de banco de dados. No quinto e no sexto captulo abordado o Modelo
Entidade-Relacionamento, bem como a tcnica de diagramao correspondente,
que usado para modelar base de dados. O stimo captulo apresenta o Modelo
Relacional. O oitavo captulo contm relato sobre o padro-SQL, linguagem usada
para estruturar e manipular banco de dados relacionais. O ltimo captulo apresenta
um sistema gerenciador de banco de dados relacional - Access - e o seu emprego
para organizar dados em uma instituio.

2. BANCOS DE DADOS

A expresso Banco de Dados originou-se do termo ingls Databanks. Este foi


trocado pela palavra Databases Base de Dados devido possuir significao mais
apropriada (SETZER; CORRA DA SILVA, 2005, p. 1).
Mas afinal, o que um banco de dados?
Segundo DATE (2004, p. 10), Um banco de dados uma coleo de dados
persistentes, usada pelos sistemas de aplicao de uma determinada empresa.
Em outras palavras, um banco de dados um local onde so armazenados dados
necessrios manuteno das atividades de determinada organizao, sendo este
repositrio a fonte de dados para as aplicaes atuais e as que vierem a existir.
Para ELMASRI e NAVATHE (2011, p. 3), na expresso Banco de Dados esto
subentendidas as propriedades abaixo:
Um banco de dados representa algum aspecto do mundo real, s vezes
chamado de minimundo ou de universo de discurso (UoD Universe of
Discourse). As mudanas no minimundo so refletidas no Banco de Dados.
Um banco de dados e uma coleo logicamente coerente de dados com
algum significado inerente. Uma variedade aleatria de dados no pode ser
corretamente chamada de banco de dados.
Um banco de dados projetado, construdo populado com dados para
uma finalidade especfica. Ele possui um grupo definido de usurios e
algumas aplicaes previamente concebidas nas quais esses usurios
esto interessados.

Assim, um banco de dados um conjunto organizado de dados relacionados, criado


com determinado objetivo e que atende uma comunidade de usurios.

2.1.

PORQUE UTILIZ-LOS

Ao armazenarmos dados em um computador podemos faz-lo de duas maneiras:


utilizando bancos de dados, ou ento, arquivos de dados permanentes. A
abordagem de banco de dados considerada a melhor forma, porque apresenta as
seguintes vantagens:

Controle centralizado de dados: os dados esto concentrados em um nico

local e isto proporciona um maior controle. Na abordagem de processamento de


arquivos os dados esto dispersos, pois cada aplicao mantm arquivos de dados
prprios.


Controle da redundncia, reduo do espao de armazenamento e

compartilhamento de dados: no processamento de arquivos convencional existe um


desperdcio do espao de armazenamento, visto que uma mesma informao
geralmente aparece em muitos arquivos diferentes. No enfoque de banco de dados
o dado armazenado apenas uma vez e pode ser compartilhado (de forma
concorrente ou no) por diversos usurios.


Eliminao de inconsistncias e garantia de integridade: no mtodo

tradicional, baseado em arquivos, dada a repetio de informao armazenada,


pode acontecer de um mesmo dado apresentar valores divergentes. Isso ocorre, por
exemplo, quando um dado que est presente em dois arquivos atualizado em
apenas um local. Diz-se que os arquivos esto inconsistentes, pois apresentam
entradas diferentes para um mesmo dado. E se falta consistncia, no h
integridade (o arquivo possui informaes incorretas). Em banco de dados
possvel manter a consistncia e a integridade dos dados.


Estabelecimento de padres e facilidade de acesso aos dados: na abordagem

de banco de dados, devido centralizao dos dados, torna-se mais propcio


instituir padres de nomenclatura e documentao. Devido a essa padronizao a
recuperao de informao mais eficiente.

Na forma convencional de

armazenamento, os dados esto espalhados em arquivos de diversos formatos e as


aplicaes que acessam esses dados foram escritas em linguagens de programao
diferentes.


Independncia de dados: no sistema de arquivos, a definio da estrutura de

armazenamento e do mtodo de acesso aos dados est inclusa no cdigo das


aplicaes. Essas so chamadas de dependentes de dados, visto que impossvel
alterar a estrutura dos arquivos de dados sem modificar o respectivo programa de
aplicao. Bancos de dados, porm, possibilitam a independncia de dados, pois
permitem a abstrao de dados (que ser discutido mais adiante).

10

3. SISTEMA DE BANCO DE DADOS

De acordo com DATE (2004, p. 6), um sistema de banco de dados um sistema


computadorizado cuja finalidade geral armazenar informaes e permitir que os
usurios busquem e atualizem essas informaes quando as solicitar. Para o autor
um sistema de banco de dados composto por dados, hardware, software e
usurios.

3.1.

DADOS

No contexto abordado esse item refere-se ao prprio banco de dados ao conjunto


de dados. Cabe aqui, porm, a conceituao do termo dado no realizada
anteriormente.

11

SETZER e CORRA DA SILVA (2005, p. 2), definem dado como uma


representao simblica (isto , feita por meio de smbolos), quantificada ou
quantificvel.
Complementando, ELMASRI e NAVATHE (2011, p. 3), afirmam que dados so
fatos conhecidos que podem ser registrados e possuem significado implcito.
Desta forma, o nmero de matrcula de um funcionrio um dado, pois para a
empresa ele um fato conhecido, contm uma semntica, representado por
smbolos (algarismos de 0 a 9 sistema numrico de base 10, logo quantificado)
sendo, portanto, passvel de registro.

3.2.

HARDWARE

Compreendem os elementos fsicos que compe o sistema de banco de dados,


como as mdias de armazenamento, os canais de entrada/sada, entre outros.

3.3.

SOFTWARE

Entre o banco de dados armazenado e os usurios h um conjunto de programas


denominado Sistema Gerenciador de Banco de dados (SGBD) (DATE, 2004, p. 8).
O principal objetivo de um SGDB proporcionar um ambiente tanto conveniente
quanto eficiente para a recuperao e armazenamento das informaes do banco de
dados (SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 1).
Para tanto, o Sistema Gerenciador de Banco de Dados disponibiliza recursos para
definir, construir, manipular, compartilhar, proteger e manter bancos de dados
(ELMASRI; NAVATHE, 2011, p. 3).
Por definio entende-se a especificao das estruturas de armazenamento
(definio dos elementos e respectivos tipos de dados que comporo os registros).
Construo envolve o armazenamento dos dados (registros e relacionamentos).
Manipulao refere-se recuperao e a atualizao incluso, excluso e
alterao de dados. Por compartilhamento, a permisso de acesso concorrente a

12

uma base de dados. Proteo diz respeito segurana contra falhas de hardware,
software e contra acesso no autorizado. Por manuteno, o suporte para o
crescimento do banco de dados (ELMASRI; NAVATHE, 2011, p. 4).

3.4.

USURIOS

Alguns usurios esto interessados no contedo do banco de dados, pois


necessitam dos dados l armazenados para desenvolverem suas atividades dirias.
Outros, porm, tem contato com o banco apenas para manter o sistema funcionando
corretamente (ELMASRI; NAVATHE, 2011, p. 9).
Destarte, SILBERSCHATZ, KORTH e SUDARSHAN (1999, p. 15), concluram que
os usurios podem ser diferenciados por suas expectativas de interao com o
sistema.
Segundo DATE (2004, p. 9), h trs categorias de usurio:


Programador de aplicao: desenvolve programas sobre o banco de dados,

ou seja, cria aplicaes que acessaro o sistema de banco de dados;




Usurio final: pblico que consulta e atualiza o banco de dados utilizando-se,

geralmente, das aplicaes desenvolvidas pelos componentes da classe de usurios


anterior. Pode ter conhecimentos da rea de tecnologia da informao (TI);


Administrador de banco de dados (DBA): responsveis por gerir o SGDB.

13

4. ARQUITETURA DE SISTEMAS DE BANCO DE DADOS

Alm das caractersticas j comentadas anteriormente, a abordagem de banco de


dados tambm permite o que chamamos de abstrao de dados. Segundo
ELMASRI e NAVATHE (2011, p. 19), a abstrao de dados refere-se supresso
de detalhes da organizao e armazenamento de dados, destacando recursos
essenciais para um melhor conhecimento desses dados. Em outras palavras,
possvel descrever o banco de dados sem ater-se a especificidades de hardware e
software.
Para descrever banco de dados no se prendendo a detalhes da forma como ele
ser implementado utilizamos modelos de dados. Na definio de ELMASRI e
NAVATHE (2011, p. 19), um modelo de dados uma coleo de conceitos que
podem ser usados para descrever a estrutura de um banco de dados. Ainda
conforme os autores, de acordo com o tipo de conceito utilizado nessa descrio, os
modelos de dados podem ser classificados em:


Modelo de dados de alto nvel ou conceitual: o mais prximo do usurio

final. Entidades, atributos e relacionamentos so alguns dos conceitos utilizados. Um


exemplo deste modelo o Modelo Entidade-Relacionamento que ser discutido
mais adiante.


Modelo de dados representativo ou de implementao: os Modelos de Dados

Relacional, Hierrquico e de Rede so exemplares deste modelo. Aqui os dados so


mostrados usando estrutura de registro.


Modelo de dados de baixo nvel ou fsico: descreve os dados do modelo

anterior para armazenamento no computador. Trata, por exemplo, do formato dos


registros e dos caminhos de acesso a esses dados.

4.1.

ESQUEMAS E INSTNCIAS

14

O conjunto de informaes contidas em determinado banco de dados, em um dado


momento, chamado instncia do banco de dados (SILBERSCHATZ; KORTH;
SUDARSHAN, 1999, p. 6). Ou seja, uma instncia o estado atual do banco de
dados. como uma fotografia da base de dados em determinado momento. Ela
tende a ser alterada com muita freqncia, pois a cada atualizao do banco de
dados insero, alterao ou excluso de dados obtm-se um novo estado.
A descrio do banco de dados denomina-se esquema. Esse definido na fase de
projeto do banco de dados e, geralmente, sofre pouca mudana (ELMASRI;
NAVATHE, 2011, p. 21). Um esquema pode usar qualquer uma das categorias de
modelos de dados vistas acima.
Fazendo uma analogia com os fundamentos das linguagens de programao, diz-se
que o valor de uma varivel em um determinado instante corresponde instncia do
banco de dados. J a definio do tipo dessa varivel corresponde ao esquema de
banco (SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 6).

4.2.

ARQUITETURA DE TRS ESQUEMAS

A arquitetura de trs esquemas, tambm conhecida como arquitetura ANSI/SPARC,


uma arquitetura para sistemas de banco de dados cujo objetivo viabilizar as
caractersticas da abordagem de banco de dados, sobretudo a independncia de
dados (ELMASRI; NAVATHE, 2011, p. 22). Ela composta composta pelos nveis:
interno, externo e conceitual.

15

De forma geral, o usurio est interessado em apenas uma parte do banco de


dados. Ento, fornecido a este usurio o acesso a apenas uma poro dos dados
armazenados. Essa parcela de dados visualizada por determinado usurio chamase viso externa. As vises externas so definidas atravs de esquemas externos. O
nvel externo ocupa-se desses esquemas.
O nvel conceitual trata da representao de toda a informao armazenada do
banco de dados viso conceitual. Diz-se que a conjuno dos vrios esquemas
externos existentes. A viso conceitual definida atravs de um esquema
conceitual.
J o nvel interno refere-se representao da estrutura do armazenamento fsico
dos dados viso interna. A viso interna definida por um esquema interno.
A figura abaixo exemplifica os trs nveis da arquitetura.

16

No nvel conceitual, o banco de dados armazena informaes relativas ao conjunto


de entidades EMPREGADO. Cada ente deste conjunto possui trs atributos:
NMERO DO EMPREGADO, NMERO DO DEPARTAMENTO E SALRIO, sendo
j discriminados seus respectivos tipo e tamanho.
No nvel externo, existem duas vises - usurio PL/I e usurio COBOL. Em ambas
as vises a entidade EMPREGADO representada por meio de um registro
contendo dois campos. Porm, o primeiro usurio enxerga o NMERO DO
EMPREGADO e o SALRIO. J o segundo v apenas o NMERO DO
EMPREGADO e o NMERO DO DEPARTAMENTO. Em cada uma das vises o
registro definido conforme convenciona a linguagem de programao utilizada pelo
usurio.
No nvel interno, a representao feita por meio de um registro armazenado
chamado EMP_ARMAZENADO que contm 20 bytes de comprimento. Esse registro
possui, entre outras caractersticas, indexao sobre o campo EMP#.
Outra questo importante da arquitetura de trs esquemas so os mapeamentos.
Denomina-se mapeamento a operao de converso de uma solicitao ou
resultado entre os nveis da arquitetura (ELMASRI; NAVATHE, 2011, p. 23). Por
exemplo, o usurio que deseja fazer uma consulta especificar sua requisio no
respectivo esquema externo. Essa ser transformada numa solicitao no esquema
conceitual mapeamento externo/conceitual que por sua vez ter uma
correspondente no esquema interno mapeamento conceitual/interno. No caminho

17

inverso, a resposta passar novamente por mapeamentos interno/conceitual e


conceitual/externo para que seja adequada viso externa deste usurio.

18

5. CICLO DE VIDA E PROJETO DE BANCO DE DADOS

Os sistemas de banco de dados, tal qual um software de aplicao, possuem um


ciclo de vida. ELMASRI e NAVATHE (2011, p. 204) particionam as atividades desse
ciclo em oito fases:


Definio do sistema, corresponde determinao do escopo do sistema, ou

seja, a deciso sobre principais usurios, quais dados devem ser armazenados e
as operaes a serem realizadas sobre eles;


Projeto do banco de dados, envolve criao dos projetos conceitual, lgico e

fsico. No projeto conceitual desenvolve-se um esquema conceitual, utilizando um


modelo de dados de alto nvel, como por exemplo o Modelo EntidadeRelacionamento, de forma a atender os requisitos apontados durante a fase de
definio do sistema. No projeto lgico, tambm conhecido como mapeamento do
modelo de dados, efetua-se uma converso do esquema criado com o modelo de
dados conceitual para o modelo de dados utilizado pelo tipo de SGDB que ser
adotado. Por tipo entenda-se o modelo de dados relacional, hierrquico, rede
adotado pelo SGDB e no o produto especfico Oracle, DB2, entre outros. E
finalmente, no projeto fsico, este sim dependente do produto SGBD escolhido, so
especificadas as estruturas de armazenamento, os ndices e caminhos de acessos
base de dados;


Implementao do banco de dados, refere-se criao do banco de dados de

fato, conforme esquemas definidos na etapa anterior;




Carga ou converso de dados, compreende o preenchimento do banco de

dados povoamento da base. Pode ocorrer pela carga de dados direta ou pela
converso de arquivos subsistentes;


Converso de aplicao, diz respeito a provveis adaptaes a serem

realizadas nos programas que acessavam o sistema anterior para que eles interajam
com o novo;


Teste e validao, trata de confrontar o sistema com suas especificaes, ou

seja, verificar se tudo est funcionando em conformidade com o que foi planejado;


Operao, relativo disponibilizao do sistema para uso; e

19

Monitoramento e manuteno, corresponde a observao e a realizao de

possveis ajustes do sistema.

20


6. O MODELO ENTIDADE-RELACIONAMENTO (E-R)

A abordagem de Entidade-Relacionamento baseada no Modelo EntidadeRelacionamento que foi introduzido por Peter Pin-Shan Chen, em 1976. um
aprimoramento do modelo originalmente proposto, sendo uma das tcnicas de
modelagem semntica mais conhecidas e, possivelmente, uma das mais utilizadas.
DATE (2004, p. 355).
Uma das principais vantagens talvez seja o motivo maior para sua popularidade
que alm de conceitos o modelo ainda conta com uma tcnica de diagramao.
Isto permite registrar e comunicar de forma simplificada os principais aspectos do
projeto de banco de dados DATE (2004, p. 358).
O modelo ER descreve os dados como entidades, relacionamentos e atributos
(ELMASRI; NAVATHE, 2011, p. 132).

6.1.

ENTIDADES E CONJUNTO DE ENTIDADES

Uma entidade uma coisa ou um objeto no mundo real que pode ser identificada
de forma unvoca em relao a todos os outros objetos (SILBERSCHATZ; KORTH;
SUDARSHAN, 1999, p. 21).
Por exemplo, cada servidor de uma instituio pblica de ensino uma entidade.
Cada unidade de ensino (campus) desse rgo tambm.
As entidades classificam-se em: entidades regulares ou fortes e entidades fracas.
Para DATE (2004, p. 355), uma entidade fraca uma entidade cuja existncia
depende de alguma outra entidade, no sentido de que ela no pode existir se essa
outra entidade tambm no existir. Os dependentes de um servidor so exemplos
clssicos de entidades fracas, pois existiro se, e somente se, existir a entidade
servidor.
J uma entidade regular ou forte, pode ser definida como uma entidade no fraca.
Por exemplo, um servidor uma entidade forte.

21

Segundo SETZER e CORRA DA SILVA (2005, p. 22), um conjunto de entidades


uma coleo de entidades que tm caractersticas semelhantes, isto , de entes de
uma mesma categoria.
Assim, o conjunto de entidades Servidores representa a coleo de todos os
servidores que trabalham naquela instituio. E o conjunto de entidades Campi
refere-se ao conjunto de todas as unidades de ensino daquele rgo.
Um conjunto de entidades representado no modelo E-R por um retngulo.

6.2.

ATRIBUTOS E DOMNIO DE VALORES

Uma entidade representada por um conjunto de atributos. Atributos so


propriedades descritivas de cada membro de um conjunto de entidades
(SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 22).
Em outras palavras, atributos so os dados que se deseja guardar sobre cada
entidade (SETZER; CORRA DA SILVA, 2005, p. 23).
Desta forma, o nome, o pronturio e a data de nomeao so possveis atributos
para cada entidade do conjunto de entidades Servidores. Endereo e sigla
comporiam os atributos de cada ente do conjunto de entidades Campi.
Os atributos podem ser classificados como:


Simples ou Compostos

De acordo com ELMASRI e NAVATHE (2011, p. 153), atributos no divisveis so


chamados atributos simples ou atmicos.
Por outro lado, atributos compostos no possuem valor elementar e podem ser
decompostos em outros atributos simples e/ou compostos (SETZER; CORRA DA
SILVA, 2005, p. 24).

22

Por exemplo, o endereo de cada servidor um atributo composto, pois pode ser
dividido em alguns atributos simples, como: Logradouro, Nmero, Complemento,
Bairro, Cidade e Estado.


Monovalorados ou Multivalorados

Um atributo monovalorado aquele que assume um nico valor para uma dada
entidade. Ao passo que, um atributo multivalorado pode ter n valores considerando
uma mesma entidade (SETZER; CORRA DA SILVA, 2005, p. 27).
Exemplificando, o atributo Sexo do conjunto de entidades Servidores um atributo
monovalorado, pois assume um nico valor masculino ou feminino para cada
entidade. Ao contrrio, o atributo Telefone considerado multivalorado, visto que um
servidor pode ter vrios telefones para contato e, consequentemente, esse atributo
assumir n valores.


Armazenados ou Derivados

Quanto ao atributo derivado SILBERSCHATZ, KORTH e SUDARSHAN (1999, p.


24), definem que o valor desse tipo de atributo pode ser derivado de outros
atributos ou entidades a ele relacionados.
O atributo Data_Exercicio que representa a data de entrada em efetivo exerccio de
cada

servidor

um

exemplo

de

atributo

armazenado.

atributo

Tempo_Contribuio que simboliza o tempo total de servios prestados instituio


um atributo derivado, porque pode ser obtido pelo valor de Data_Exerccio e pela
data atual.


Nulos

Um atributo nulo usado quando uma entidade no possui valor para determinado
atributo (SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 24).
O atributo Nmero_Reservista do conjuntos de entidades Servidores um atributo
nulo, pois no se aplica a todas entidades (servidoras no possuem Carteira de
Reservista).


Chaves ou Determinantes

SETZER e CORRA DA SILVA (2005, p. 31), definem que dado um conjunto de


entidades, no h duas entidades desse conjunto com o mesmo valor para aquele
atributo. Em outras palavras, dado um valor para esse atributo, esse valor determina
a qual entidade ele est associado.

23

Por exemplo, Pronturio um atributo chave, pelo motivo de identificar de forma


unvoca cada ente no conjunto de entidades Servidores. No h dois servidores com
um mesmo nmero de pronturio.
Ainda sobre atributos, outro ponto importante o que se denomina domnio de
valores. Um domnio de valores diz respeito ao conjunto de valores que determinado
atributo pode assumir para cada entidade. Ou seja, conforme esclarece DATE
(2004, p. 356), um atributo tira seus valores de um conjunto de valores
correspondente (isto , domnio, em outras palavras).
Por exemplo, em determinada instituio pblica o servidor pode, conforme o cargo
ocupado, cumprir uma jornada de trabalho de 20, 30 ou 40 horas semanais.
Considerando que Carga_Horria seja um dos atributos de Servidores, o conjunto
formado pelos valores 20, 30 e 40 compem o domnio dessa propriedade, uma vez
que Carga_Horria tem, obrigatoriamente, que assumir um desses trs valores.
No modelo E-R atributos so representados por elipses, conforme notao abaixo:

6.3.

RELACIONAMENTOS E CONJUNTOS DE RELACIONAMENTOS

Um relacionamento uma associao entre uma ou vrias entidades


(SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 24).
Ilustrando, quando nos referimos ao local onde cada servidor desempenha suas
atividades sua lotao este dado no se refere somente Servidores e nem
unicamente Campi, mas sim a ambos. Esse elemento dependente de uma e outra

24

entidade representado no MER pelo que se denomina relacionamento. Ento, em


nosso exemplo, dizemos que os entes em Servidores esto associados aos entes
em Campi atravs do relacionamento Lotao.
Um conjunto de relacionamentos um conjunto de relacionamentos do mesmo tipo
(SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 25). No modelo E-R conjuntos
de relacionamentos so representados por losangos.

Devemos ler o diagrama anterior da seguinte maneira: Servidores tm como lotao


Campi, da esquerda para a direita; e Campi lotao de Servidores, da direta para a
esquerda.
As entidades envolvidas em determinado relacionamento so ditas participantes
desse relacionamento. O nmero de participantes em determinado relacionamento
chamado grau desse relacionamento (DATE, 2004, p. 357).
Assim, no exemplo anterior tem-se um relacionamento de grau dois (tambm
conhecido como relacionamento binrio), pois h dois conjuntos de entidades
participantes: Servidores e Campi.
Relacionamentos, da mesma forma que entidades, podem ter atributos descritivos
(SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 25). Por exemplo, suponhamos
que os servidores possam, a interesse da administrao pblica, ser removidos de
um plo de trabalho a outro e que seja necessrio armazenar em banco de dados o
histrico das remoes efetuadas. Ento, ao relacionamento Lotao, que associa
Servidores e Campi, agrega-se o atributo Data_Incio que representar a data de
admisso do funcionrio em um dado campus. Desta maneira, registraremos a
movimentao do servidor em cada um dos campi nos quais ele venha a trabalhar.

25

6.4.

AUTO-RELACIONAMENTOS

Relacionamentos entre entidades de mesma categoria denominam-se autorelacionamentos (SETZER; CORRA DA SILVA, 2005, p. 47).
Mas, como compreender um relacionamento entre entidades de tipo?
Segundo ELMASRI e NAVATHE (2011, p. 141), cada tipo de entidade que participa
de um tipo de relacionamento desempenha nele uma funo em particular.
SILBERSCHATZ, KORTH e SUDARSHAN (1999, p. 25), complementam dizendo
que a funo que uma entidade desempenha em um relacionamento chamada
papel. Ento, em um auto-relacionamento (tambm denominado relacionamento
recursivo) as entidades so do mesmo tipo, porm elas tm papis diferentes.
Por exemplo, determinada autarquia federal precisa realizar concurso pblico para
preencher vagas de emprego. Ento, a autoridade mxima do rgo o Reitor
designa uma comisso que ser responsvel por todos os trabalhos referentes ao
processo seletivo. Essa comisso, por sua vez, pode delegar tarefas para grupos de
trabalhos menores. Ento, tem-se o seguinte cenrio: uma comisso coordena
comisses menores, sendo essas ltimas subordinadas quela primeira. Isso pode
ser modelado atravs de um auto-relacionamento, onde o conjunto de entidades
Comisso associa-se a ele mesmo atravs do relacionamento Superviso, de
maneira que Comisso ora desempenha o papel de supervisora, ora de
supervisionada.

6.5.

RESTRIES SOBRE TIPOS DE RELACIONAMENTO

26

De acordo com ELMASRI e NAVATHE (2011, p. 142), os tipos de relacionamentos


costumam ter certas restries que limitam as combinaes de entidades que
podem participar no conjunto de relacionamentos correspondente. Ainda segundo
os autores, essas restries que so estabelecidas de acordo com realidade que se
modelada, dividem-se em dois grupos: razo de cardinalidade e participao.

6.5.1. RAZO DE CARDINALIDADE OU CARDINALIDADE

Na definio de ELMASRI e NAVATHE (2011, p. 142), a razo de cardinalidade


especifica o nmero mximo de instncias de relacionamento em que uma entidade
pode participar.
Em outras palavras, a cardinalidade expressa o nmero de entidades s quais outra
entidade

pode

estar

associada

via

um

conjunto

de

relacionamentos

(SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 28). Conforme exemplificam


esses autores, dado um conjunto de entidades A, um conjunto de entidades B e um
conjunto de relacionamentos R (associao entre A e B), com relao
cardinalidade, tem-se uma das situaes abaixo:


UM PARA UM (1:1): cada entidade do conjunto de entidades A est

associada a no mximo uma entidade do conjunto de entidades B, e cada entidade


em B est associada a no mximo uma entidade em A.


UM PARA MUITOS (1:N): uma entidade em A est associada a diversas

entidades em B, mas cada entidade em B est associada a no mximo a uma


entidade de A.


MUITOS PARA MUITOS ( M:N): uma entidade em A est associada a vrias

entidades em B, e uma entidade de B est associada a diversas entidades em A.

27

6.5.2. RESTRIES DE PARTICIPAO E DEPENDNCIA DE EXISTNCIA

Para ELMASRI e NAVATHE (2011, p. 143), a restrio de participao especifica o


nmero mnimo de instncias de relacionamento em que cada entidade pode
participar. Ainda segundo os autores, as restries de participao classificam-se
em total e parcial.
Considerando ainda os conjuntos de entidades A, entidades B e relacionamentos R,
temos que a participao de A em R dita total de todos os elementos em A
participam de pelo menos um relacionamento R. Caso contrrio, se apenas uma
parte dos entes em A associam-se aos elementos em B atravs de R, a participao
de A em R chamada de parcial.
Outra questo importante, mas que est fortemente ligada restrio de
participao do tipo total, a dependncia de existncia. Vamos explic-la por meio
do seguinte exemplo: se a participao de A em R total, isto significa que a
existncia das entidades em A dependem da existncia das entidades em B. Ento,
A dito dependente de B.
No modelo E-R, a participao total (no mnimo um) representada por linha dupla
ligando o conjunto de entidades ao relacionamento correspondente. J a
participao parcial (nenhum mnimo) exibida por linha simples.

28

O diagrama acima significa que um servidor tem como dependente no mnimo


nenhum e no mximo muitos dependentes. Por outro lado, um dependente
dependente de no mnimo um e no mximo um servidor. Ou seja, podero existir
funcionrios que no possuem dependentes, porm todo dependente deve estar
associado a um servidor.

29

7. O MODELO ENTIDADE-RELACIONAMENTO ESTENDIDO (EER)

Os conceitos bsicos do Modelo de Entidade-Relacionamento (E-R) so suficientes


para construir o esquema de grande parte dos bancos de dados. Contudo, algumas
situaes so modeladas de maneira mais correta utilizando recursos adicionais
ditos extenses do E-R. Essas ferramentas compreendem os conceitos de
super/subclasse, herana de atributos, especializao e generalizao. Todas elas,
juntamente com os conceitos E-R vistos at aqui, compem o denominado Modelo
de Entidade-Relacionamento Estendido (EER).

7.1.

SUPERCLASSES, SUBCLASSES E HERANA DE ATRIBUTOS

Um conjunto de entidades pode conter subgrupos de entidades que so, de alguma


forma, diferentes de outras entidades do conjunto (SILBERSCHATZ; KORTH;
SUDARSHAN, 1999, p. 39).
Essa diferena consiste, por exemplo, em atributos que so especficos de
determinado subtipo do conjuntos de entidades, ou ainda, relacionamentos que se
aplicam somente a um dado subgrupo.
Por exemplo, o conjunto de entidades Servidores pode ser subdividido em
Estatutrios (servidores regidos pelo Regime Jurdico nico RJU) e Celetistas
(servidores regidos pela Consolidao das Leis Trabalhistas CLT). Celetistas
possuem o atributo CTPS (Carteira de Trabalho e Previdncia Social) que prprio
dessa subcategoria. Estaturios possuem os atributos Portaria e Data_Publicao
(nmero do ato legal de nomeao e sua respectiva data de publicao no Dirio
Oficial da Unio) que somente se aplicam a eles. Ento, embora Estatutrios e
Celetistas

pertenam

ao

conjunto

de entidades

subcategorias com caractersticas peculiares.

Servidores,

eles

formam

30

Ainda, aproveitando o exemplo acima, diz-se que Celetistas e Estatutrios so


subtipos ou subclasses do tipo de entidades Servidores e o tipo de entidades
Servidores um supertipo ou superclasse para cada uma das subclasses.
Um ponto importante referente s subclasses a herana de atributos. Segundo
DATE (2004, p. 357) as propriedades e os relacionamentos que se aplicam ao
supertipo so herdados pelo subtipo. Assim, todos os atributos e relacionamento
de Servidores aplicam-se a Estatutrios e Celetistas. Porm, vale salientar que o
inverso no verdadeiro nem todos os atributos de Estatutrios e Celetistas
podem pertencer a Servidores.

7.2.

ESPECIALIZAES E GENERALIZAES

Especializao o processo de definir um conjunto de subclasses de um tipo de


entidade (ELMASRI; NAVATHE, 2011, p. 163).
SILBERSCHATZ, KORTH e SUDARSHAN (1999, p. 40), esclarecem que uma
especializao representada no modelo EER por um tringulo com o rtulo ISA (do
termo ingls is a, correspondente a um(a)).
Utilizando o exemplo anterior, tem-se que um Estatutrio um Servidor e que um
Celetista um Servidor.

Os

smbolos

usados

para

representar

as

subclasses,

seus

atributos

relacionamentos so os mesmos que usamos na superclasse, ou seja, os mesmos


vistos at aqui.

31

Generalizao pode ser dita como o contrrio da especializao. De acordo com


ELMASRI e NAVATHE (2011, p. 164), neste processo ns suprimimos as
diferenas entre vrios tipos de entidade, identificamos suas caractersticas comuns
e as generalizamos em uma nica superclasse da qual os tipos de entidade
originais so subclasses especiais.
Diz-se que a especializao um processo top-down (do geral para o especfico)
enquanto

generalizao

bottom-up

(do

especfico

para

geral)

(SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 41).


Em nosso exemplo, Servidores generaliza Celetistas e Estatutrios.

7.2.1. RESTRIES DE ESPECIALIZAES E GENERALIZAES

Segundo ELMASRI e NAVATHE (2011, p. 164), algumas restries podem ser


aplicadas especializaes e generalizaes.

A primeira delas consiste em

determinar quais entidades comporo cada uma das subclasses. Essa determinao
d-se pela escolha de um dos critrios a seguir:


Definio por condio ou predicado: condiciona-se a admisso na subclasse

ao valor que determinado atributo assume para uma dada entidade. Ou ainda, de
acordo com o valor de um atributo da superclasse a entidade alocada na

32

subclasse. Por exemplo, todas as entidades Servidores possuem o atributo


Regime_Trabalho.

Apenas

aquelas

entidades

que

atendam

condio

Regime_Trabalho = RJU so includas na subclasse Estatutrios. Somente as


entidades que satisfaam a condio Regime_Trabalho = CLT podem pertencer
ao subtipo Celetista.
Definida pelo usurio: quando no h como estabelecer uma condio para a

escolha das entidades que estaro na subclasse. De acordo com os autores, nesses
casos a condio de membro especificada individualmente para cada entidade
pelo

usurio,

no

por

qualquer

condio

que

possa

ser

avaliada

automaticamente.
O segundo tipo de restrio determina se uma dada entidade pode pertencer a mais
de uma subclasse. Assim, as subclasses podem ser:


Mutuamente exclusivas: uma entidade da superclasse pode pertencer a no

mximo uma subclasse. No exemplo utilizado, as subclasses so mutuamente


exclusivas, porque cada entidade pertence a um, e somente um, subtipo.


Sobrepostas: cada entidade da superclasse pode integrar uma ou mais

subclasses.
A

terceira

restrio

especifica

se

toda

entidade

da

superclasse

tem,

obrigatoriamente, que pertencer a uma das subclasses. Essa restrio pode ser:


Total: quando toda entidade da superclasse deve pertencer a uma subclasse.

A generalizao Servidores total, pois todas as entidades de Servidores integram


os subtipos Celetistas e Estatutrios.


Parcial: uma entidade da superclasse pode (ou no) pertencer a uma

subclasse.

33

8. O MODELO RELACIONAL

O Modelo Relacional (MR) um modelo de dados representativo (ou de


implementao) que foi proposto por Ted Codd, em 1970. O modelo fundamenta-se
em conceitos da matemtica teoria dos conjuntos e lgica de predicado. Os
primeiros sistemas comerciais baseados no MR foram disponibilizados em 1980 e
desde ento ele vem sendo implementado em muitos sistemas, tais como Access,
Oracle, MySql, entre outros (ELMASRI; NAVATHE, 2011, p. 38).
Para DATE (2004, p. 67), o modelo relacional refere-se a trs aspectos principais
dos dados: a estrutura de dados, a integridade de dados e a manipulao de
dados.

8.1.

O ASPECTO ESTRUTURAL

No Modelo Relacional o banco de dados representado como um conjunto de


relaes. Considerando que uma relao , de certo modo, similar a uma tabela de
valores e aplicando a terminologia do MR diz-se que as linhas denominam-se tuplas;
as colunas, atributos; e a tabela em si, relao (ELMASRI; NAVATHE, 2011, p. 39).

CARGOS
Codigo

Denominacao

Classe

Categoria

701001

Adminitrador

Tcnico-Administrativo

701010

Bibliotecrio - Documentalista

Tcnico-Administrativo

701244

Tcnico de Labooratrio - rea

Tcnico-Administrativo

701405

Auxiliar em Administrao

Tcnico-Administrativo

702001

Professor de Ensino Bsico, Tcnico e Tecnolgico

Docente

O conjunto de valores que cada atributo pode assumir chama-se domnio


(SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 62).
Seja Dn, onde D o domnio de determinado atributo e n a posio do atributo na
relao e considerando a relao Cargos (figura 13), tem-se que D1 domnio do

34

atributo Codigo, pois representa o conjunto de todos os possveis cdigos de cargo.


D2 o domnio de Denominacao, porque denota o conjunto de todas as
nomenclaturas de cargo. D3 domnio de Classe, visto que representa o conjunto de
todas as classes de cargo, e assim por diante.
Ainda segundo SILBERSCHATZ, KORTH e SUDARSHAN (1999, p. 62), uma
relao definida matematicamente como um subconjunto do produto cartesiano de
uma lista de domnios. Desta forma, a relao Cargos denotada por D1xD2xD3xD4,
ou seja, Cargos um subconjunto do conjunto de todas as combinaes possveis
de valores.
Um esquema de relao (ou scheme de relao) utilizado para descrever uma
relao. Um esquema indicado por R(A1, A2,c,An), onde R o nome da relao e
An so seus atributos

(ELMASRI; NAVATHE, 2011, p. 40). Por exemplo,

Cargos(Codigo, Denominacao, Classe, Categoria) representa o esquema da relao


Cargos.
O nmero de atributos de um esquema de relao denominado grau ou aridade
(ELMASRI; NAVATHE, 2011, p. 40). Cargos, por exemplo, uma relao de grau
trs.
Uma instncia de relao (ou estado de relao) um conjunto de tuplas seus
valores num dado momento. O estado r do esquema R, denotado por r(R), um
conjunto de tuplas r={t1, t2,c, tn}, onde cada tupla t formada por uma lista de
valores t=(v1, v2, c, vn), em que cada valor vi est no domnio do respectivo atributo
Ai (ELMASRI; NAVATHE, 2011, p. 40). Exemplificando, a instncia do esquema da
relao Cargos (figura 13) composta de cinco tuplas, cada tupla uma lista de
quatro valores (por exemplo, na primeira tupla temos os seguintes valores: 701001,
Administrador, E, Tcnico-Administrativo), sendo cada valor elemento do domnio do
atributo correspondente (701001 est no domnio do atributo Cdigo, Administrador
est no domnio de Denominacao, E est no domnio de Classe e TcnicoAdministrativo est no domnio de Categoria).

8.2.

O ASPECTO DE INTEGRIDADE

35

Discutiremos nesta seo os conceitos de: superchave, chave, chave candidata,


chave primaria, chave nica (ou chave alternativa), chave estrangeira e integridade
referencial.
Uma superchave um conjunto de um ou mais atributos que, tomados
coletivamente, nos permitem identificar de maneira unvoca uma entidade em um
conjunto de entidades (SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 32).
Na relao Cargos (Figura 13), os conjuntos {Codigo, Categoria} e {Denominacao,
Classe}, por exemplo, so superchaves. Porm, {Classe, Categoria} no , visto que
h para esse conjunto de atributos tuplas que tem as mesmas combinaes de
valores.
Na definio de DATE (2004, p. 233), um conjunto de atributos dito chave se
satisfazer as condies de:
1) Unicidade: esta a propriedade atendida pelas superchaves, conforme
especificado anteriormente. Ou seja, para um dado conjunto de atributos no h na
relao tuplas com valores iguais.
2) Irredutibilidade: estabelece que no deve existir no conjunto de atributos chamado
chave um subconjunto que tenha a propriedade de unicidade. Em outras palavras,
alm de seguir a primeira regra, a chave deve ser um conjunto mnimo de atributos.
Por exemplo, o conjunto {Codigo, Denominacao} no uma chave, porque embora
satisfaa a primeira regra acaba quebrando a segunda {Codigo} e {Denominao},
tomados separadamente, j identificam exclusivamente cada tupla na relao
Cargos. O conjunto {Codigo} um exemplo de chave, pois atende simultaneamente
as duas condies acima.
Uma relao pode possuir mais de uma chave, sendo cada uma delas chamada de
chave candidata (ELMASRI; NAVATHE, 2011, p. 45). {Codigo} e {Denominacao},
por exemplo, so chaves candidatas.
A chave candidata usada para identificar tuplas em uma dada relao denomina-se
chave primria. As demais chaves candidatas dessa relao so ditas chaves
nicas. Indica-se uma chave primria sublinhando no esquema da relao os
atributos que a compem (ELMASRI; NAVATHE, 2011, p. 45).
Ilustrando,

esquema

da

relao

Denominacao, Classe, Categoria).

Cargos

ficaria

assim:

Cargos(Codigo,

36

Tendo por base o exposto por SETZER e CORRA DA SILVA (2005, p. 124),
discutiremos os conceitos de chave estrangeira e integridade referencial por meio de
um exemplo.
(a)

NOME

CLASSE

PRONTUARIO

CATEGORIA

DENOMINACAO

CODIGO

CARGOS

OCUPAO

ADMISSAO

SERVIDORES

(b) CARGOS
Codigo

Denominacao

Classe

Categoria

SERVIDORES
Prontuario

Nome

Admissao

Codigo

FIGURA 14 (a) DIAGRAMA ENTIDADE-RELACIONAMENTO. (b) RELAES CARGOS E SERVIDORES.

Considerando a representao acima, interpretamos do Diagrama EntidadeRelacionamento (figura 14a) que cada ente do conjunto de entidades Servidores
ocupa no mnimo e no mximo um cargo. Entretanto, um cargo pode ser ocupado
por nenhum ou muitos servidores. Mapeando essa situao para o Modelo
Relacional,

obtem-se

os

seguintes

esquemas

de

relao:

Cargos(Codigo,

Denominacao, Classe, Categoria) e Servidores(Prontuario, Nome, Admissao,


Codigo). Consequentemente, existiro duas relaes conforme figura 14b.
Observe que o relacionamento Ocupao entre os conjuntos de entidades
Servidores e Cargos, ocorre no Modelo Relacional (figura 14b) atravs da
transposio do atributo Codigo de Cargos para Servidores. Esse atributo transposto
em Servidores (tem como origem a relao Cargos e como destino a relao
Servidores) denomina-se chave estrangeira. Uma tupla em Servidores faz referncia
a uma tupla de Cargos, sendo que essa referncia realizada atravs do valor
contido no atributo Codigo.
Chama-se integridade referencial a regra de que o valor contido na chave
estrangeira de Servidores deve corresponder a um valor de chave primria em
Cargos. Em outras palavras, a integridade referencial a restrio de que o banco
de dados no pode conter quaisquer valores de chaves estrangeiras no
correspondentes (DATE, 2004, p. 237).

37

8.3.

O ASPECTO MANIPULATIVO

Uma linguagem de consulta a linguagem por meio da qual os usurios obtm


informaes do banco de dados (SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p.
68).
De acordo com SETZER e CORRA DA SILVA (2005, p. 172), foram definidas duas
linguagens de acesso ao modelo relacional: a lgebra Relacional e o Clculo
Relacional.
Segundo SILBERSCHATZ, KORTH e SUDARSHAN (1999, p. 68), as linguagens de
consulta podem ser classificadas em procedurais ou no-procedurais, sendo a
lgebra Relacional um exemplar da primeira modalidade e o Clculo Relacional um
exemplo da segunda.
Em uma linguagem de consulta procedural necessrio especificar todas as
operaes a serem realizados sobre o banco de dados para a obteno da
informao desejada. Ao contrrio, em uma linguagem no-procedural, descreve-se
a informao desejada sem especificar o procedimento para obt-la.
A abordagem das linguagens de lgebra e Clculo Relacional est fora do escopo
deste trabalho, porm, para fixar a definio dada acima utilizaremos o seguinte
exemplo: considerando o esquema da relao Cargos, digamos que seja necessrio
saber a denominao e a categoria dos cargos cuja classe seja C.
Para cumprir a tarefa proposta utilizando a lgebra Relacional, devemos saber quais
operadores usar e em que ordem eles sero aplicados. Obrigatoriamente, temos que
saber: a) que sero necessrios dois operadores (o de Seleo, indicado por
(sigma), e o operador Projeo, indicado por (pi)) e b) que primeiro deve ser
executada a seleo, e depois a projeo. Assim, a expresso final teria a seguinte
forma:

Classe = C (Cargos))

Denominao, Categoria(

J utilizando o Clculo Relacional, necessrio especificar apenas o que


desejamos. Desta forma, especificarmos quais os atributos desejados para cada
tupla, informamos que essas tuplas esto na relao Cargos e que devem ser

38

listadas somente aquelas cujo valor do atributo Classe seja C. A instruo em


Clculo Relacional teria a seguinte sintaxe:
{ t.Denominacao, t.Categoria | Cargos(t) and t.Classe = C}

39

9. O PADRO-SQL

A Structured Query Language (SQL) ou Linguagem de Consulta Estruturada foi


criada pela IBM Research, no incio da dcada de 1970, para o prottipo de um
sistema de banco de dados chamado System R (DATE, 2004, p. 71).
Baseada nas linguagens de lgebra e Clculo Relacional, e inicialmente
denominada SEQUEL (Structured English QUEry Language), SQL hoje a
linguagem padro para Sistemas Gerenciadores de Bancos de Dados Relacionais
(SGBDR), sendo mais intelegvel do que suas linguagens maternas consideradas
tcnicas demais para o usurio (ELMASRI; NAVATHE, 2011, p. 57).
A SQL padronizada pelo American National Standards Institute (ANSI) e pela
International Standards Organization (ISO), conjuntamente. A primeira versopadro, chamada de SQL-86 (ou SQL1), foi lanada em 1986 e desde ento ela vem
sendo atualizada SQL-92 (ou SQL2), SQL:1999 (ou SQL3), SQL:2003, SQL:2006
e, ainda, uma outra atualizao ocorreu em 2008 (ELMASRI; NAVATHE, 2011, p.
57).
Apesar de conhecida como uma linguagem de consulta, a SQL oferece tambm
recursos para definir a estrutura dos dados, atualizar incluir, excluir e alterar
dados,

especificar

restries

de

integridade

outros

recursos

mais

(SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 109).


De acordo com DATE (2004, p. 85), a SQL possui, entre outros, os seguintes
componentes: Data Definition Language (DDL) ou Linguagem de Definio de
Dados e Data Manipulation Language (DML) ou Linguagem de Manipulao de
Dados.

9.1.

LINGUAGEM DE DEFINIO DE DADOS

A DDL usada para especificar relaes, domnios, regras de integridade, entre


outros. O comando create, que na viso de ELMASRI e NAVATHE (2011, p. 58) a

40

principal instruo para a definio de dados, utilizado para criar tabelas,


assertions, domnios, triggers e mais. A DDL tambm inclui as intrues alter e drop.

9.1.1. INSTRUO CREATE TABLE

Os termos relao, tupla e atributo do Modelo Relacional correspondem tabela,


linha e coluna, respectivamente, na SQL (DATE, 2004, p. 72).
A instruo create table usada para criar uma tabela. Na viso de SETZER e
CORRA DA SILVA (2005, p. 174), a declarao de uma tabela resume-se
descrio do seu esquema, dos domnios, de integridades referenciais e certas
restries de integridade
Antes de seguirmos adiante, discutiremos os conceitos de tipo de dado (domnio) e
restries (de atributo, chave e integridade referencial).

9.1.1.1.

Domnios e tipos de dados

Um mtodo comum de especificao de um domnio definir um tipo de dado do


qual so retirado os valores de dados que formam o domnio (ELMASRI;
NAVATHE, 2011, p. 39).
Os tipos de dados podem ser definidos pelo sistema (tambm conhecidos como
internos ou embutidos) ou definidos pelo usurio (DATE, 2004, p. 96).
De acordo com SILBERSCHATZ, KORTH e SUDARSHAN (1999, p. 138), os
principais tipos disponibilizados pelo padro SQL (tipos embutidos) so:


char(n): para sequncia de caracteres de tamanho fixo, em que o tamanho n

definido pelo usurio;




varchar(n): para sequncia de caracteres de tamanho varivel, em que o

tamanho mximo n definido pelo usurio;




int: para nmeros inteiros;

smallint: para nmeros inteiros pequenos ( um subconjunto de int);

41

numeric(p,d): para nmeros de ponto fixo, em que p a quantidade total de

dgitos que compe o nmero e d especifica quantos desses dgitos esto direita
(aps o ponto decimal). Um numeric(5,2) permite armazenar um nmero com cinco
dgitos, sendo que dois deles esto aps o ponto decimal, ou seja, o nmero
armazenado deve possuir o seguinte formato 999.99.


real e double precision: para nmeros de ponto flutuante e ponto flutuante de

preciso dupla, em que a preciso depende do equipamento utilizado.




float(n): para nmeros de ponto flutuante, em que a preciso n definida pelo

usurio. Assim, float(2) armazena nmeros com duas casas decimais.




date: para datas, inclui ano, ms e dia; e

time: para horrios, inclui hora, minuto e segundo.

Um domnio pode ser declarado e seu nome usado com a especificao do atributo
(ELMASRI; NAVATHE, 2011, p. 61). So os tipos de dados definidos pelo usurio.
Para isso usamos a instruo create domain, conforme abaixo:
create domain <nome do domnio> as <tipo de dado>
Por exemplo, vamos declarar o domnio Moeda e utiliz-lo mais adiante na
especificao do atributo Salario.
create domain Moeda as numeric(9,2)

9.1.1.2.

Restries de atributo, chave e integridade referencial

De acordo com ELMASRI e NAVATHE (2011, p. 61), podemos especificar restries


de atributo, chave e integridade referencial como parte da criao de tabelas atravs
do acrscimo de algumas clusulas:


not null: usada para especificar atributos cujo valor no possa ser vazio, ou

seja, estabelece que a coluna da tabela no conter valores nulos.




default: define um valor padro para dado atributo. Deste modo, ao se criar

uma nova linha na tabela, esse valor ser automaticamente atribudo coluna caso
nenhum valor seja explicitamente informado. Se a clusula default for omitida, o
valor padro null para aqueles atributos que no contenham a restrio not null.


check: empregada para limitar os valores de um atributo. Assim, toda linha da

tabela deve satisfazer a condio especificada na clusula check.

42

primary key: usada para especificar a chave primria de uma relao.

unique: aplicada na especificao da chave nica de uma relao.

foreign key: utilizada para especificar a chave estrangeira de uma relao.

Essa clusula tambm impe integridade referencial ao banco de dados.




constraint: opcionalmente utilizada para nomear uma restrio. Restries

com um nome so passveis de excluso ou substituio, caso necessrio.


As trs primeiras clusulas not null, default e check so ditas restries de
atributo. Primary key e Unique so restries de chave. Foreign key uma restrio
de integridade referencial. A sintaxe de cada clusula ser exposta por meio de
exemplo, conforme veremos adiante.
Retomando o ponto onde paramos, segundo SILBERSCHATZ, KORTH e
SUDARSHAN (1999, p. 139), a instruo create table possui a seguinte forma:
create table r (A1D1, A2D2, c, AnDn,
<regras de integridade1>,
c,
<regras de integridadek>),
onde r o nome da relao, Ai o nome do atributo no esquema da relao r e Di
o domnio do atributo Ai. As regras de integridade incluem restries de atributo,
chave e integridade referencial.
Para exemplificar o comando create table, considere os seguintes esquemas de
relao:
Cargos(Codigo, Denominacao, Classe, Categoria)
Campi(Sigla, Cidade)
Servidores(Prontuario, SIAPE, Nome, Admissao, Salario, CodCargos, CodCampi)
Aplicando os conceitos discutidos, podemos especificar esses esquemas atravs
das instrues SQL abaixo:
create table Cargos
(Codigo char(6) not null,
Denominacao varchar(50) not null,
Classe char(1) default E,
Categoria varchar(22) check(Categoria in (Tecnico-Administrativo, Docente),
constraint ChPCargos primary key (Codigo))

43

create table Campi


(Sigla char(8) not null,
Cidade varchar(25),
constraint ChPCampi primary key (Sigla))
create table Servidores
(Prontuario char(6) not null,
SIAPE char(7) not null,
Nome varchar(70),
Admissao date,
Salario Moeda,
CodCargos char(6) not null,
CodCampi char(6) not null,
constraint ChPServidores primary key (Prontuario),
constraint ChAServidores unique (SIAPE),
constraint ChEServCargo foreign key (CodCargos) references Cargos (Codigo),
constraint ChEServCampi foreign key (CodCampi) references Campi (Sigla))
Aqui, criamos uma tabela denominada Cargos que possui quatro colunas. Dissemos
que a segunda coluna (Denominacao) no aceita valores nulos. A primeira coluna
(Codigo) a chave primria (primary key) da tabela Cargos e por esse motivo
tambm no permite valores nulos. Especificamos que o valor padro (default) para
Classe E. Atravs da clusula check determinamos que Categoria deve assumir
o valor Tcnico-Administrativo ou Docente. E, ainda, definimos uma restrio
(constraint) de chave primria chamada ChPCargos.
Criamos tambm uma tabela Campi com duas colunas Sigla (que chave
primria) e Cidade e tambm uma restrio de chave primria denominada
ChPCampi.
A ltima tabela (Servidores) composta por sete colunas, sendo: Prontuario, uma
chave primria; SIAPE, uma chave nica (ou alternativa); CodCargos, uma chave
estrangeira que referencia a tabela Cargos; CodCampi; uma chave estrangeira que
referencia a tabela Campi; e mais trs colunas, Nome, Admissao e Salario (note
que para especificar esse atributo usamos o nome do domnio que foi definido
anteriormente). Alm disso, existem quatro restries: duas de chave estrangeira

44

(ChEServCargo e ChEServCampi), uma de chave nica (ChAServidores) e outra de


chave primria (ChPServidores).
Abordaremos agora outros dois importantes comandos pertencentes DDL drop e
alter.

9.1.2. INSTRUO DROP

O comando DROP pode ser usado para remover elementos nomeados do


esquema, como tabelas, domnios ou restries (ELMASRI; NAVATHE, 2011, p.
91). Ele possui a seguinte sintaxe:
drop <tipo do elemento> <nome do elemento>
Suponha, por exemplo, a necessidade de excluir a tabela Servidores, assim como o
domnio Moeda. As respectivas instrues seriam definidas assim:
drop table Servidores
drop domain Moeda

9.1.3. INSTRUO ALTER

A instruo alter permite modificar a estrutura de uma tabela, bem como alterar a
definio de outros elementos nomeados de um esquema. Considerando uma
tabela, tem-se a oportunidade de adicionar e excluir colunas, modificar a definio
de colunas, e ainda, acrescentar ou eliminar restries para a tabela (ELMASRI;
NAVATHE, 2011, p. 61).
Entre outras, podemos utilizar o comando alter das seguintes formas:


alter table <nome da tabela> add column <nome da coluna> <tipo de dado>,

para acrescentar uma coluna a uma tabela;




alter table <nome da tabela> drop column <nome da coluna>, para remover

uma coluna de uma tabela;




alter table <nome da tabela> add constraint <nome da restrio>, para

adicionar uma restrio a uma tabela; e

45

alter table <nome da tabela> drop constraint <nome da restrio>, para excluir

uma restrio de uma tabela.

9.2.

LINGUAGEM DE MANIPULAO DE DADOS

Uma vez definido o banco de dados possvel operar sobre ele atravs das
operaes de manipulao: select, insert, update e delete (DATE, 2004, p. 73).
Select usada para realizar consultas ao banco de dados, enquanto insert, update e
delete

so

aplicadas

na

insero,

atualizao

excluso

de

dados,

respectivamente.

9.2.1. INSTRUO SELECT

De acordo com ELMASRI e NAVATHE (2011, p. 86), um comando select pode


incluir at seis clusulas:
select <lista de atributos e funes>
from <lista de tabelas>
where <condio>
group by <atributo de agrupamento>
having <condio de grupo>
order by <lista de atributos>,
devendo a instruo seguir essa ordem e sendo obrigatrias apenas as duas
primeiras clusulas select e from.

9.2.1.1.

Clusulas select e from

A clusula select usada para elencar os atributos desejados no resultado da


consulta, e from, para especificar em qual ou quais tabelas eles so encontrados.

46

Considerando a tabela Cargos, podemos, por exemplo, criar a instruo:


select Codigo, Denominacao
from Cargos
para listar somente as colunas (atributos) Codigo e Denominacao da tabela Cargos.
Agora considere a seguinte consulta: apresente todas as classes da tabela cargos.
select Classe
from Cargos
O resultado da consulta uma tabela com apenas uma coluna onde aparecem os
valores de classe. Contudo, alguns desses valores podem aparecer duplicados caso
tenhamos na tabela dois ou mais cargos que possuam a mesma classe (o que
bem provvel). Para forar a eliminao dos valores duplicados no resultado dessa
consulta devemos acrescentar a palavra reservada distinct.
select distinct Classe
from Cargos
Assim, asseguramos que cada valor D, por exemplo, aparea uma nica vez no
resultado da consulta. Entretanto, se desejarmos que de fato apaream todos os
valores podemos declar-lo de forma explcita por meio da palavra-chave all.
select all Classe
from Cargos
O comando select sem distinct ou all, todavia, correspondente a select all
(ELMASRI; NAVATHE, 2011, p. 68)
Caso seja necessrio listar na consulta todas as colunas de uma tabela, podemos
utilizar o sinal de asterisco (*) ao invs de especificar os atributos na clusula select.
Desse modo,
select *
from Cargos
equivalente a
select Codigo, Denominacao, Classe, Categoria
from Cargos.
A clusula select pode ainda conter expresses aritmticas envolvendo constantes
ou atributos e operadores de +, -, * e / (SILBERSCHATZ; KORTH; SUDARSHAN,
1999, p. 112). Considerando a tabela Servidores, a instruo
select Nome, Salario * 12
from Servidores

47

lista o nome e o salrio bruto anual de cada servidor, sendo essa ltima coluna
obtida pela multiplicao do salrio percebido pela quantidade de meses no ano.
Tabelas (relaes) e colunas (atributos) podem ser renomeadas atravs da clusula
as (SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 114). Tomemos como
ilustrao o resultado da consulta realizada acima. Nela a coluna onde aparecer o
salrio bruto anual no ter um nome. Ento, podemos atribu-lo por meio da
clusula as, conforme segue:
select Nome, Salario * 12 as Sal_Bruto_Anual
from Servidores

9.2.1.2.

Clusula where

A clusula where denotada por where<condio>, onde <condio> uma


expresso condicional (booleana) que identifica as tuplas a serem recuperadas pela
consulta (ELMASRI; NAVATHE, 2011, p. 64). Em outras palavras, todas as tuplas
resultantes de uma consulta onde where esteja presente devem satisfazer a
condio especificada nessa clusula.
Por exemplo, a consulta encontre o nome de todos os servidores que percebem
salrio acima de R$1.000,00 especificada em SQL da seguinte forma:
select Nome
from Servidores
where Salario > 1000
Assim, a consulta seleciona em Servidores as linhas que atendam a condio de
where (Salario>1000) e ento projeta o resultado no atributo Nome.
Para montar condies na clusula where possvel utilizar operadores de
comparao (>, <, =, >=, <=, <> e between) e conectores lgicos (and, or e not)
(SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 113). Para ilustrar, veja como
fica a sintaxe da consulta selecione o pronturio e o nome dos servidores que foram
admitidos entre 02/04/2010 e 07/09/2011.
select Prontuario, Nome
from Servidores
where Admissao between 02/04/2010 and 07/09/2011

48

Na clusula where possvel estabelecer condies que envolvam a comparao de


substrings por meio do operador like associado ao caracter reservado %
(porcentagem) ou _ (sublinhado), onde % representa uma cadeia de caracteres e _
denota um nico caracter (SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 115).
Por exemplo, suponhamos que deva ser montada uma lista de todos os servidores
cujos nomes iniciam-se com a letra A. Para atender a essa solicitao seria
necessria a seguinte consulta:
select Nome
from Servidores
where Nome like A%
Consideremos agora uma consulta que envolva colunas de duas tabelas, como
para os cargos que possuem ao menos um servidor, relacione o nome do servidor e
o cargo por ele ocupado.
De acordo com SETZER e CORRA DA SILVA (2005, p. 179), para fazer uma
consulta envolvendo duas tabelas ligadas, sempre necessrio colocar no
predicado a condio de juno. Essa condio justamente a igualdade das duas
colunas.
Ora, a chave primria de Cargos (Codigo) foi transposta em Servidores
(CodCargos). Logo, CodCargos e Codigo so correspondentes. Assim, para
solucionar a questo anterior teramos a consulta:
select Nome, Denominacao
from Servidores, Cargos
where CodCargos = Codigo

9.2.1.3.

Clusulas group by

Antes de tratarmos da clusula group by discutiremos funes agregadas.


So ditas funes agregadas as funes que recebem como entrada um conjuntos
de valores, produzindo como sada um nico valor. Compreendem as funes avg,
min, max, sum e count, empregadas no clculo de mdia, mnimo, mximo,
totalizao

de

valores

totalizao

de

quantidades,

(SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 120).

respectivamente

49

Suponha a consulta encontre a quantidade total de servidores da instituio. Para


obter esse quantitativo podemos, por exemplo, totalizar a quantidade de pronturios
existentes na tabela Servidores, conforme segue:
select count (Prontuario)
from Servidores
Essa consulta tem como resultado uma tabela formada por uma nica linha e coluna
onde consta a quantidade total de servidores do rgo.
Agora, sofisticando um pouco a consulta anterior, imagine que devamos encontrar a
quantidade total de servidores em cada campus da instituio. Primeiro
necessrio dividir os servidores em grupos de acordo com o seu local de trabalho e
depois efetuar a contagem dos respectivos pronturios por meio de count.
A clusula SQL group by utilizada justamente quando precisamos aplicar funes
agregradas subgrupos do total de linhas, sendo que esses grupos sero formados
a partir dos atributos constantes na clusula group by (SILBERSCHATZ; KORTH;
SUDARSHAN, 1999, p. 120). Enquanto as funes de agregao so usadas para
resumir informaes de vrias tuplas em uma sntese de tupla nica. O
agrupamento usado para criar subgrupos de tuplas antes do resumo (ELMASRI;
NAVATHE, 2011, p. 82).
A instruo correspondente ao exemplo adotado ficaria assim:
select Denominacao, count (Prontuario)
from Servidores, Campi
where CodCampi = Sigla
group by Denominacao

9.2.1.4.

Clusula having

Imagine que para a consulta anterior seja necessrio encontrar apenas os campi
que possuem trinta ou mais servidores. Para atender essa demanda empregaremos
a clusula having.
Uma clusula having possibilita selecionar somente grupos cujos componentes
atendam a uma determinada condio (SETZER; CORRA DA SILVA, 2005, p.
184). No entanto, importante ressaltar que having e where desempenham funes

50

diferentes. A clusula HAVING est para grupos como a clusula WHERE esta para
linhas; em outras palavras, HAVING usada para eliminar grupos, da mesma
maneira que WHERE usada para eliminar linhas (DATE, 2004, p. 204).
A tabela resultante pode ser obtida da seguinte forma:
select Denominacao, count (Prontuario)
from Servidores, Campi
where CodCampi = Sigla
group by Denominacao
having count (Prontuario) >= 30

9.2.1.5.

Clusula order by

O ltimo possvel componente de um comando select order by. Uma clusula


order by usada para indicar que se deseja um ordenamento ascendente (asc) ou
descendente (desc) para as linhas que compe a tabela resultante, sendo a
classificao ascendente o padro, caso no seja explicitamente especificada uma
ordem.
Para a ordenao descendente da coluna Denominacao no resultado da consulta
anterior, teramos:
select Denominacao, count (Prontuario)
from Servidores, Campi
where CodCampi = Sigla
group by Denominacao
having count (Prontuario) >= 30
order by Denominacao desc
SETZER e CORRA DA SILVA (2005, p. 185), sintetizam de forma muito clara o
funcionamento de comando select (com todas as suas possveis clusulas), da
seguinte forma:
Conceitualmente, a execuo de cada select segue a seguinte
ordem. 1. A clusula where testada produzindo com isso juno
e/ou seleo de linhas. 2. feito o agrupamento das linhas
resultantes usando-se os valores das colunas do group by. 3. So
escolhidos apenas os grupos que satisfazem a clusula having, que
sempre aplicada a cada grupo como um todo e no individualmente

51

s suas linhas. 4. As linhas assim resultantes so ordenadas pelas


colunas indicadas no order by. 5. feita a projeo na lista de
colunas do select, eventualmente com clculo de funes de
agregao que so aplicadas a todas as linhas resultantes de cada
grupo.

9.2.2. INSTRUO INSERT

O comando insert usado para inserir dados em uma tabela, mais especificamente
inserir linhas na tabela.
No comando de insero podemos informar somente os valores a serem includos,
porm devemos faz-lo na mesma ordem em que as colunas (atributos) aparecem
na tabela. Assim, para acrescentar novos dados tabela Cargos temos que
apresentar valores, obrigatoriamente, na seguinte ordem: em primeiro lugar o cdigo
do cargo; em segundo, sua nomenclatura; em terceiro, a classe a qual ele pertence;
e por ltimo, a categoria na qual ele se enquadra.
insert into Cargos
values (701711, Auxiliar em Enfermagem, C, Tecnico-Administrativo)
Entretanto, tambm possvel determinar a ordem em que os valores sero
acrscidos tabela especificando seus respectivos atributos na instruo insert.
Considerando a tabela Cargos, para incluso dos mesmos valores acima
informados, mas em uma ordem diferente, escreveramos:
insert into Cargos (Denominacao, Categoria, Codigo, Classe)
values (Auxiliar em Enfermagem, Tecnico-Administrativo, 701711, C)

9.2.3. INSTRUO DELETE

A instruo delete usada para eliminar linhas em tabela. O comando possui a


seguinte sintaxe:
delete from <nome da tabela>
where <condio>,

52

onde <nome da tabela> a tabela de onde sero excludas as linhas e <condio>


um filtro que selecionar as linhas que sero eliminadas.
Por exemplo, imagine que devamos excluir da tabela Cargos todos os cargos cuja
classe seja A. Isso pode ser realizado com:
delete from Cargos
where Classe = A

9.2.4. INSTRUO UPDATE

O comando update usado para alterar o valor de determinado atributo de uma ou


vrias linhas em uma tabela.
Para ilustrar, considere que seja necessrio conceder um aumento de 10% a todos
os servidores. Faramos isso atravs da instruo update abaixo:
update Servidores
set Salario = Salario + Salario * 0,01
Agora, suponha que o aumento deva ser concedido apenas aos servidores que
percebem salrio inferior a R$ 1.500, 00. Isso pode ser feito com:
update Servidores
set Salario = Salario + Salario * 0,01
where Salario < 1500
Encerramos aqui nossa breve explanao sobre a SQL. No abordamos todos os
tpicos pertencentes linguagem, haja vista que propsito deste trabalho apenas
introduzir o assunto.

53

10. ESTUDO DE CASO: MICROSOFT OFFICE ACCESS E O IFSP

O Microsoft Office Access, ou denominado simplesmente Access, um aplicativo


voltado para a criao e a manipulao de bancos de dados relacionais. Ele compe
a sute de programas do pacote Office que atualmente est em sua verso 2010.
Na definio acima usamos o termo aplicativo, pois na literatura existe uma gama
de classificaes distintas. Alguns o consideram um Sistema Gerenciador de Banco
de Dados; outros, porm, chegam a dizer que no se trata nem de um banco de
dados.
Contudo, para uma conceituao mais formal, compartilhamos da viso de
CARVALHO (2006, p. 451), cujo entendimento de que o Microsoft Access um
SGBDR de pequeno porte para ser usado com bancos de dados pessoais e de
pequenas e mdias empresas.
De acordo com OLIVEIRA (2005, p. 6), embora o Access tenha algumas limitaes,
ainda assim ele adequado para tratar uma quantidade razovel dados, porque
atende aos pequenos sistemas e prepara os dados para um futuro up. Ou seja, ele
uma possvel soluo para a necessidade organizar dados e ainda um bom
precedente adoo de sistemas gerenciadores de bancos de dados relacionais
mais robustos como, por exemplo, o SQL SERVER.
SETZER e CORRA DA SILVA (2005, p. 215), em complemento, dizem que o
Access apresenta as seguintes vantagens:


um sistema amplamente conhecido e que possui compatibilidade com suas

verses anteriores;


de fcil utilizao e possui interface amigvel; e

no requer conhecimentos profundos sobre a teoria bancos de dados.

Entretanto, cabe aqui a nota de que no requerer informao aprofundada sobre


banco de dados no significa no ter nenhum conhecimento sobre a rea. Alis,
para OLIVEIRA (2005, p. 3), esse um dos motivos pelo qual o Access temido,
porque exige do usurio o conhecimento de uma srie de conceitos como registros,
campos, relacionamentos, banco de dados, entre outros.

54

Desta forma, para criar e manter de forma otimizada um banco de dados Access
muito recomendado o entendimento e a aplicao de todos os conceitos vistos nos
captulos anteriores: Modelo Entidade-Relacionamento, para a modelagem do banco
de dados; Modelo Relacional, para o mapeamento do Diagrama EntidadeRelacionamento; e SQL, para a construo e manuteno da base de dados.

10.1. UMA VISO GERAL DO ACCESS

Um banco de dados Access constitudo por alguns elementos chamados objetos.


Os objetos que compe um banco Access so tabelas, consultas, formulrios,
relatrios, macros e mdulos.

10.1.1.

TABELAS

Como em qualquer modelo relacional, a estrutura de dados bsica do Access


consiste em tabelas (SETZER; CORRA DA SILVA, 2005, p. 219).
Tabelas so elementos formados por colunas e linhas, onde cada coluna
corresponde a um campo, e cada linha, a um registro.
Uma coluna definida pelo seu nome, pelo tipo de dados que pode receber e por
um comentrio. O comentrio opcional (SETZER; CORRA DA SILVA, 2005, p.
220).
Uma tabela pode ser criada de algumas maneiras, entre elas:


no Modo Design, usando interface grfica, conforme figura 15. O item 1 o

nome da tabela; 2 onde especificamos o nome da coluna; em 3 definimos o tipo de


dado que ser armazenado; em 4 colocamos, opcionalmente, uma descrio do
contedo que a coluna ir armazenar; 5 onde definimos as propriedade do campo,
como: tamanho, valor padro (default), requerido (se aceita valores nulos ou no),
entre outros; e 6 apresenta indicativo de que o campo uma chave primria.

55

atravs de uma consulta de Definio de Dados, onde podemos escrever o

comando SQL diretamente. A mesma tabela da figura 15 agora criada com a


instruo SQL (Figura 16).

10.1.2.

CONSULTAS

Uma consulta, para o Access, to somente uma expresso SQL armazenada para
uso posterior CARVALHO (2006, p. 455).
Segundo SETZER e CORRA DA SILVA (2005, p. 229), o Access possibilita a
criao de dois tipos de consulta: seleo e ao. O primeiro tipo permite recuperar

56

dados do banco de dados. O segundo tipo implementa comandos para a atualizao


incluso, excluso e alterao no banco.
Considerando esses tipos, encontram-se no Access as seguintes consultas:


Seleo: tem por base a instruo SQL select e usada para selecionar

campos e registros das tabelas do banco de dados;




Acrscimo: origina-se da instruo insert into e serve para adicionar registros

s tabelas;


Excluso: construda a partir da instruo delete, utilizada para excluir

registros das tabelas do banco de dados;




Atualizao: baseada na instruo update e permite alterar os valores dos

campos em uma tabela;




Criar Tabela: contm a instruo create table e possibilita a criao de uma

tabela no banco de dados.


Todas as consultas anteriores podem ser realizadas atravs da interface abaixo
(Figura 17), selecionando o do tipo de consulta desejada (item 2) ou diretamente
atravs de instrues SQL, no Modo SQL (item 1).

Por exemplo, considerando a tabela criada na figura 16 (tabela Campi), suponha que
seja necessrio listar todos seus campos (colunas), porm em ordem ascendente
pelo campo Cidade. Poderamos montar essa consulta conforme ilustrado na figura
18 ou 19 das duas maneiras obteramos o mesmo resultado.

57

10.1.3.

FORMULRIOS

Um formulrio um objeto de banco de dados por meio do qual possvel exibir e


inserir dados em tabelas. Em outras palavras, formulrios servem de interface para
insero e visualizao (em tela) de dados do banco de dados. Por exemplo,
poderamos montar um formulrio (uma tela) para incluso de novos campi, assim
como para exibio daqueles j existentes na tabela.

58

10.1.4.

RELATRIOS

Um relatrio, que costuma estar vinculado a tabelas ou consultas, uma


representao impressa de dados. Ou seja, usado para apresentar os dados
(sada, geralmente impressa). Imagine, por exemplo, que haja a necessidade de
imprimir uma lista com o nome de todos dos campi. Para atender a essa solicitao
montaramos um relatrio que, alm do nome de cada campus, poderia conter
nmero da pgina, o logo da instituio e a data em que foi impresso.

10.1.5.

MACROS

O Access permite a construo de comandos denominados macros para


automatizar tarefas. Por exemplo, no formulrio para a visualizao e insero de
novos campi, poderamos criar um boto de comando que, ao ser pressionado,
automaticamente enviaria o relatrio com o nome de todos os campi cadastrados
para a impressora padro.

10.1.6.

MDULOS

O Visual Basic for Applications (VBA) possibilita o desenvolvimento de programas


ditos mdulos dentro do Access. Com o VBA podemos usar variveis, estruturas
de deciso (if, else, select case), estruturas de repetio (do while, do until, for next),
functions, procedures e demais ferramentas disponibilizadas por uma linguagem de
programao. Para ilustrar, embora seja um exemplo irreal, considere que devamos
classificar os registros da tabela campi em extenso ou curto de acordo com
quantidade de caracteres que compem a string presente na coluna Cidade.
Poderamos criar um procedimento que percorresse a tabela campi e avaliasse cada

59

registro primeiramente, efetuando a contagem de letras da cadeia de caracteres


contida em Cidade e depois realizando a classificao.

10.2. INSTITUTO FEDERAL DE SO PAULO

O Instituto Federal de Educao, Cincia e Tecnologia (IFSP) uma autarquia


federal, vinculada ao Ministrio da Educao (MEC), que possui autonomia
administrativa e didtico-pedaggica. Ele uma instituio que oferta cursos
regulares de educao bsica (Ensino Mdio), profissional (Cursos Tcnicos) e
superior (Bacharelados, Licenciaturas, Tecnologias, Ps-Graduao lato-sensu e
stricto-sensu).
Atualmente, alm da Reitoria, o Instituto Federal de So Paulo conta com vinte e oito
unidades de ensino, sendo vinte e quatro campi convencionais e quatro campi
avanados. Seu corpo docente e tcnico-administrativo constitudo, em sua grande
maioria, por servidores do quadro permanente de pessoal que regido pelo Regime
Jurdico nico (RJU).
Entre outros pontos, o RJU que configura a Lei n 8112/90 estabelece que a
forma de ingresso no rgo ocorrer mediante realizao de concurso pblico e que
os novos servidores estaro sujeitos a avaliao desempenho em estgio probatrio
durante os primeiros trinta e seis meses de efetivo exerccio, devendo ocorrer uma
avaliao a cada doze meses.

10.3. IFSP E UTILIZAO DO ACCESS

De acordo com as normas internas do IFSP, especificamente a Resoluo n


93/2005, cabe Diretoria de Recursos Humanos (setor pertencente Reitoria)
operacionalizar as avaliaes dos servidores admitidos em todos os campi desde
a abertura do processo, quando da primeira avaliao, at a homologao do
resultado, aps a ltima avaliao.

60

Desta forma, obrigatrio que haja um controle mensal referente aos processos que
devem ser abertos, os que esto em andamento, assim como aqueles que devem
ser homologados.
Antes do Plano de Expanso da Rede Federal de Educao Tecnolgica plano
que multiplicou o nmero de Institutos Federais em todo o territrio nacional o
Instituto Federal de So Paulo executava todo o processo de avaliaes quase que
de forma manual, contando apenas com os programas Microsoft Word (para montar
relatrios) e Microsoft Excel (para controlar prazos). Entretanto, aps o Plano de
Expanso, essa situao tornou-se insustentvel, visto que o nmero de
contrataes cresceu muito.
Ento, para suprir essa necessidade de organizar dados, foi que se passou a utilizar
o Microsoft Access.

Hoje so retirados do sistema todos os formulrios necessrios na montagem dos


processos de avaliao, assim como possvel saber a situao de cada um deles.
Consultas ad-hoc tambm podem ser executadas sempre que desejado.

61

62

11. CONSIDERAES FINAIS

A abordagem de bancos de dados apresenta vantagens se comparada com o


processamento de arquivos tradicional, entre os benefcios esto a independncia, a
integridade e a consistncia de dados, assim como o controle de redundncia.
Um esquema de banco de dados diz respeito estrutura do banco de dados.
Esquemas podem ser descritos atravs de modelos de dados.
Da mesma forma que softwares de aplicao, um bancos de dados desenvolvido
por meio de projeto, sendo que esse compreende diversas etapas. Merecem
destaque o projeto conceitual, no qual se emprega o Modelo EntidadeRelacinamento para descrever dados e sua semntica; e o projeto lgico, que o
mapeamento do modelo conceitual para o modelo de dados do SGBD que ser
adotado. Ainda hoje, a maior parte dos bancos de dados so relacionais, portanto,
emprega-se nessa converso o Modelo Relacional.
O Microsoft Access um Gerenciador de Banco de Dados Relacional e como tal
suporta a SQL principal linguagem de consulta a bancos de dados relacionais.
Embora ele componha a sute de programas do pacote Microsoft Office, difere dos
demais programas, como o Word ou o Excel, pois exige do usurio conhecimento da
teoria de banco de dados. A vantagem de sua adoo est principalmente na
facilidade de uso (devido interface grfica) e na disponibilizao de recursos do
VBA linguagem de programao embutida no Access. uma alternativa de
soluo para iniciar o tratamento de dados atravs da abordagem de banco de
dados.

63

12. REFERNCIAS

SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S.. SISTEMA DE


BANCO DE DADOS. 3. ed. So Paulo: Makron Books, 1999.
ELMASRI, Ramez; NAVATHE, Shamkant B.. SISTEMAS DE BANCO DE DADOS.
6. ed. So Paulo: Addison Wesley, 2011.
DATE, C. J.. INTRODUO A SISTEMAS DE BANCOS DE DADOS. 8. ed. Rio de
Janeiro: Elsevier, 2003.
SETZER, Valdemar W.; SILVA, Flvio Soares Corra da. BANCOS DE DADOS:
APRENDA O QUE SO, MELHORE SEU CONHECIMENTO, CONSTRUA OS
SEUS. So Paulo: Edgard Blcher, 2005.
OLIVEIRA, Marcos Raul de. ADMINISTRAAO DE EMPRESAS COM ACCESS.
So Paulo: Digerati Books, 2005.
CARVALHO, Joao Antonio. INFORMATICA PARA CONCURSOS. 3. ed. Rio de
Janeiro: Elsevier, 2006.
BRASIL. Instituto Federal de So Paulo. ESTATUTO. Disponvel em: <
http://www.ifsp.edu.br/index.php?option=com_content&view=article&id=76&Itemid=1
09>. Acesso em: 30 nov. 2011.
BRASIL. Instituto Federal de So Paulo. Resoluo n 93, de 15 de setembro de
2005. Dispe sobre os procedimentos e instrumentos para Avaliao de
Desempenho dos servidores Docentes e Tcnicos Administrativos em Estgio
Probatrio. Disponvel em:
<http://www.ifsp.edu.br/index.php?option=com_phocadownload&view=category&id=
82:resolues-2005&Itemid=149>. Acesso em: 30 nov. 2011.

BRASIL. Lei n 8.112, de 11 de dezembro de 1990. Dispe sobre o regime jurdico


dos servidores pblicos civis da Unio, das autarquias e das fundaes pblicas
federais. Disponvel em: < http://www.planalto.gov.br/ccivil_03/LEIS/L8112cons.htm
>. Acesso em: 30 nov. 2011.