Escolar Documentos
Profissional Documentos
Cultura Documentos
São Paulo
2011
ELISÂNGELA ROCHA DA COSTA
São Paulo
2011
AGRADECIMENTOS
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.
1. INTRODUÇÃO ............................................................................................... 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. USUÁRIOS .................................................................................................. 12
4. ARQUITETURA DE SISTEMAS DE BANCO DE DADOS .......................... 13
4.1. ESQUEMAS E INSTÂNCIAS ....................................................................... 13
4.2. ARQUITETURA DE TRÊS 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 DOMÍNIO DE VALORES ..................................................... 21
6.3. RELACIONAMENTOS E CONJUNTOS DE RELACIONAMENTOS ............ 23
6.4. AUTO-RELACIONAMENTOS ...................................................................... 25
6.5. RESTRIÇÕES SOBRE TIPOS DE RELACIONAMENTO ............................ 25
6.5.1. RAZÃO DE CARDINALIDADE OU CARDINALIDADE................................. 26
6.5.2. RESTRIÇÕES DE PARTICIPAÇÃO E DEPENDÊNCIA DE EXISTÊNCIA .. 27
7. O MODELO ENTIDADE-RELACIONAMENTO ESTENDIDO (EER)........... 29
7.1. SUPERCLASSES, SUBCLASSES E HERANÇA DE ATRIBUTOS ............. 29
7.2. ESPECIALIZAÇÕES E GENERALIZAÇÕES ............................................... 30
7.2.1. RESTRIÇÕES DE ESPECIALIZAÇÕES E GENERALIZAÇÕES ................. 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 PADRÃO-SQL ......................................................................................... 39
9.1. LINGUAGEM DE DEFINIÇÃO DE DADOS.................................................. 39
9.1.1. INSTRUÇÃO CREATE TABLE .................................................................... 40
9.1.1.1. Domínios e tipos de dados ......................................40
9.1.1.2. Restrições de atributo, chave e integridade referencial
41
9.1.2. INSTRUÇÃO DROP ..................................................................................... 44
9.1.3. INSTRUÇÃO ALTER.................................................................................... 44
9.2. LINGUAGEM DE MANIPULAÇÃO DE DADOS ........................................... 45
9.2.1. INSTRUÇÃO SELECT ................................................................................. 45
9.2.1.1. Cláusulas select e from ..........................................45
9.2.1.2. Cláusula where .....................................................47
9.2.1.3. Cláusulas group by ................................................48
9.2.1.4. Cláusula having.....................................................49
9.2.1.5. Cláusula order by ..................................................50
9.2.2. INSTRUÇÃO INSERT .................................................................................. 51
9.2.3. INSTRUÇÃO DELETE ................................................................................. 51
9.2.4. INSTRUÇÃO UPDATE................................................................................. 52
10. ESTUDO DE CASO: MICROSOFT OFFICE ACCESS E O IFSP ............... 53
10.1. UMA VISÃO GERAL DO ACCESS .............................................................. 54
10.1.1. TABELAS .................................................................................................. 54
10.1.2. CONSULTAS ............................................................................................ 55
10.1.3. FORMULÁRIOS ........................................................................................ 57
10.1.4. RELATÓRIOS ........................................................................................... 58
10.1.5. MACROS .................................................................................................. 58
10.1.6. MÓDULOS ................................................................................................ 58
10.2. INSTITUTO FEDERAL DE SÃO PAULO ..................................................... 59
10.3. IFSP E UTILIZAÇÃO DO ACCESS .............................................................. 59
11. CONSIDERAÇÕES FINAIS ......................................................................... 62
12. REFERÊNCIAS ........................................................................................... 63
7
1. INTRODUÇÃO
Os bancos de dados estão 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 seções seguintes uma
introdução aos conceitos fundamentais de banco de dados. Considerando que os
bancos de dados são em sua grande maioria ainda relacionais, esse trabalho os
enfatizará. Assim, o primeiro capítulo conceitua banco de dados e também discute
as vantagens advindas dessa abordagem. O segundo capítulo define sistema de
banco de dados, assim como discorre brevemente sobre cada elemento que o
compõe. O terceiro capítulo descreve abstração e modelo de dados para então
discorrer sobre a arquitetura para sistemas de banco de dados ANSI/SPARC. O
quarto capítulo oferece uma visão geral das etapas de desenvolvimento de um
projeto de banco de dados. No quinto e no sexto capítulo é abordado o Modelo
Entidade-Relacionamento, bem como a técnica de diagramação correspondente,
que é usado para modelar base de dados. O sétimo capítulo apresenta o Modelo
Relacional. O oitavo capítulo contém relato sobre o padrão-SQL, linguagem usada
para estruturar e manipular banco de dados relacionais. O último capítulo apresenta
um sistema gerenciador de banco de dados relacional - Access - e o seu emprego
para organizar dados em uma instituição.
8
2. BANCOS DE DADOS
De acordo com DATE (2004, p. 6), um sistema de banco de dados é “um sistema
computadorizado cuja finalidade geral é armazenar informações e permitir que os
usuários busquem e atualizem essas informações quando as solicitar”. Para o autor
um sistema de banco de dados é composto por dados, hardware, software e
usuários.
3.1. DADOS
3.2. HARDWARE
3.3. SOFTWARE
uma base de dados. Proteção” diz respeito à segurança contra falhas de hardware,
software e contra acesso não autorizado. Por manutenção, o suporte para o
crescimento do banco de dados (ELMASRI; NAVATHE, 2011, p. 4).
3.4. USUÁRIOS
6. O MODELO ENTIDADE-RELACIONAMENTO (E-R)
“Uma entidade é uma ‘coisa’ ou um ‘objeto’ no mundo real que pode ser identificada
de forma unívoca em relação a todos os outros objetos” (SILBERSCHATZ; KORTH;
SUDARSHAN, 1999, p. 21).
Por exemplo, cada servidor de uma instituição pública de ensino é uma entidade.
Cada unidade de ensino (campus) desse órgão também.
As entidades classificam-se em: entidades regulares ou fortes e entidades fracas.
Para DATE (2004, p. 355), uma entidade fraca é “uma entidade cuja existência
depende de alguma outra entidade, no sentido de que ela não pode existir se essa
outra entidade também não existir”. Os dependentes de um servidor são exemplos
clássicos de entidades fracas, pois existirão se, e somente se, existir a entidade
servidor.
Já uma entidade regular ou forte, pode ser definida como uma entidade não fraca.
Por exemplo, um servidor é uma entidade forte.
21
Por exemplo, o endereço de cada servidor é um atributo composto, pois pode ser
dividido em alguns atributos simples, como: Logradouro, Número, 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; CORRÊA 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 contrário, o atributo Telefone é considerado multivalorado, visto que um
servidor pode ter vários 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 exercício de
cada servidor é um exemplo de atributo armazenado. Já o atributo
Tempo_Contribuição que simboliza o tempo total de serviços prestados à instituição
é um atributo derivado, porque pode ser obtido pelo valor de Data_Exercício e pela
data atual.
Nulos
“Um atributo nulo é usado quando uma entidade não possui valor para determinado
atributo” (SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 24).
O atributo Número_Reservista do conjuntos de entidades Servidores é um atributo
nulo, pois não se aplica a todas entidades (servidoras não possuem Carteira de
Reservista).
Chaves ou Determinantes
SETZER e CORRÊA DA SILVA (2005, p. 31), definem que “dado um conjunto de
entidades, não 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
Devemos ler o diagrama anterior da seguinte maneira: Servidores têm como lotação
Campi, da esquerda para a direita; e Campi é lotação de Servidores, da direta para a
esquerda.
“As entidades envolvidas em determinado relacionamento são ditas participantes
desse relacionamento. O número de participantes em determinado relacionamento é
chamado grau desse relacionamento” (DATE, 2004, p. 357).
Assim, no exemplo anterior tem-se um relacionamento de grau dois (também
conhecido como relacionamento binário), 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 administração pública, ser removidos de
um pólo de trabalho a outro e que seja necessário armazenar em banco de dados o
histórico das remoções efetuadas. Então, ao relacionamento Lotação, que associa
Servidores e Campi, agrega-se o atributo Data_Início que representará a data de
admissão do funcionário em um dado campus. Desta maneira, registraremos a
movimentação do servidor em cada um dos campi nos quais ele venha a trabalhar.
25
6.4. AUTO-RELACIONAMENTOS
“Um conjunto de entidades pode conter subgrupos de entidades que são, de alguma
forma, diferentes de outras entidades do conjunto” (SILBERSCHATZ; KORTH;
SUDARSHAN, 1999, p. 39).
Essa “diferença” consiste, por exemplo, em atributos que são específicos 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
Estatutários (servidores regidos pelo Regime Jurídico Único – RJU) e Celetistas
(servidores regidos pela Consolidação das Leis Trabalhistas – CLT). Celetistas
possuem o atributo CTPS (Carteira de Trabalho e Previdência Social) que é próprio
dessa subcategoria. Estatuários possuem os atributos Portaria e Data_Publicação
(número do ato legal de nomeação e sua respectiva data de publicação no Diário
Oficial da União) que somente se aplicam a eles. Então, embora Estatutários e
Celetistas pertençam ao conjunto de entidades Servidores, eles formam
subcategorias com características peculiares.
30
8. O MODELO RELACIONAL
CARGOS
Codigo Denominacao Classe Categoria
701001 Adminitrador E Técnico-Administrativo
701010 Bibliotecário - Documentalista E Técnico-Administrativo
701244 Técnico de Labooratório - Área D Técnico-Administrativo
701405 Auxiliar em Administração C Técnico-Administrativo
702001 Professor de Ensino Básico, Técnico e Tecnológico D Docente
Tendo por base o exposto por SETZER e CORRÊA DA SILVA (2005, p. 124),
discutiremos os conceitos de chave estrangeira e integridade referencial por meio de
um exemplo.
(a) CLASSE
PRONTUARIO
NOME
DENOMINACAO CATEGORIA ADMISSAO
CODIGO
1 N
CARGOS OCUPAÇÃO SERVIDORES
(b) CARGOS
Codigo Denominacao Classe Categoria
SERVIDORES
Prontuario Nome Admissao Codigo
(sigma), e o operador Projeção, indicado por π (pi)) e b) que primeiro deve ser
executada a seleção, e depois a projeção. Assim, a expressão final teria a seguinte
forma:
listadas somente aquelas cujo valor do atributo Classe seja “C”. A instrução em
Cálculo Relacional teria a seguinte sintaxe:
{ t.Denominacao, t.Categoria | Cargos(t) and t.Classe = “C”}
39
9. O PADRÃO-SQL
Aqui, criamos uma tabela denominada Cargos que possui quatro colunas. Dissemos
que a segunda coluna (Denominacao) não aceita valores nulos. A primeira coluna
(Codigo) é a chave primária (primary key) da tabela Cargos e por esse motivo
também não permite valores nulos. Especificamos que o valor padrão (default) para
Classe é “E”. Através da cláusula check determinamos que Categoria deve assumir
o valor “Técnico-Administrativo” ou “Docente”. E, ainda, definimos uma restrição
(constraint) de chave primária chamada ChPCargos.
Criamos também uma tabela Campi com duas colunas – Sigla (que é chave
primária) e Cidade – e também uma restrição de chave primária denominada
ChPCampi.
A última tabela (Servidores) é composta por sete colunas, sendo: Prontuario, uma
chave primária; 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 três colunas, Nome, Admissao e Salario (note
que para especificar esse atributo usamos o nome do domínio que foi definido
anteriormente). Além disso, existem quatro restrições: duas de chave estrangeira
44
A instrução alter permite modificar a estrutura de uma tabela, bem como alterar a
definição de outros elementos nomeados de um esquema. Considerando uma
tabela, tem-se a oportunidade de adicionar e excluir colunas, modificar a definição
de colunas, e ainda, acrescentar ou eliminar restrições 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 restrição>, para
adicionar uma restrição a uma tabela; e
45
alter table <nome da tabela> drop constraint <nome da restrição>, para excluir
uma restrição de uma tabela.
Uma vez definido o banco de dados é possível operar sobre ele através das
operações de manipulação: select, insert, update e delete (DATE, 2004, p. 73).
Select é usada para realizar consultas ao banco de dados, enquanto insert, update e
delete são aplicadas na inserção, atualização e exclusão de dados,
respectivamente.
lista o nome e o salário bruto anual de cada servidor, sendo essa última coluna
obtida pela multiplicação do salário percebido pela quantidade de meses no ano.
Tabelas (relações) e colunas (atributos) podem ser renomeadas através da cláusula
as (SILBERSCHATZ; KORTH; SUDARSHAN, 1999, p. 114). Tomemos como
ilustração o resultado da consulta realizada acima. Nela a coluna onde aparecerá o
salário bruto anual não terá um nome. Então, podemos atribuí-lo por meio da
cláusula as, conforme segue:
select Nome, Salario * 12 as Sal_Bruto_Anual
from Servidores
Imagine que para a consulta anterior seja necessário “encontrar apenas os campi
que possuem trinta ou mais servidores”. Para atender essa demanda empregaremos
a cláusula having.
Uma cláusula having possibilita selecionar somente grupos cujos componentes
atendam a uma determinada condição (SETZER; CORRÊA DA SILVA, 2005, p.
184). No entanto, é importante ressaltar que having e where desempenham funções
50
diferentes. “A cláusula HAVING está para grupos como a cláusula 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
O comando insert é usado para inserir dados em uma tabela, mais especificamente
inserir linhas na tabela.
No comando de inserção podemos informar somente os valores a serem incluídos,
porém 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 código
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, também é possível determinar a ordem em que os valores serão
acréscidos à tabela especificando seus respectivos atributos na instrução insert.
Considerando a tabela Cargos, para inclusão dos mesmos valores acima
informados, mas em uma ordem diferente, escreveríamos:
insert into Cargos (Denominacao, Categoria, Codigo, Classe)
values (“Auxiliar em Enfermagem”, “Tecnico-Administrativo”, “701711”, “C”)
Desta forma, para criar e manter de forma otimizada um banco de dados Access é
muito recomendado o entendimento e a aplicação de todos os conceitos vistos nos
capítulos anteriores: Modelo Entidade-Relacionamento, para a modelagem do banco
de dados; Modelo Relacional, para o mapeamento do Diagrama Entidade-
Relacionamento; e SQL, para a construção e manutenção da base de dados.
10.1.1. TABELAS
10.1.2. CONSULTAS
“Uma consulta, para o Access, é tão somente uma expressão SQL armazenada para
uso posterior” CARVALHO (2006, p. 455).
Segundo SETZER e CORRÊA DA SILVA (2005, p. 229), o Access possibilita a
criação de dois tipos de consulta: seleção e ação. O primeiro tipo permite recuperar
56
Por exemplo, considerando a tabela criada na figura 16 (tabela Campi), suponha que
seja necessário listar todos seus campos (colunas), porém em ordem ascendente
pelo campo Cidade. Poderíamos montar essa consulta conforme ilustrado na figura
18 ou 19 – das duas maneiras obteríamos o mesmo resultado.
57
10.1.3. FORMULÁRIOS
10.1.4. RELATÓRIOS
10.1.5. MACROS
10.1.6. MÓDULOS
Desta forma, é obrigatório que haja um controle mensal referente aos processos que
devem ser abertos, os que estão em andamento, assim como aqueles que devem
ser homologados.
Antes do Plano de Expansão da Rede Federal de Educação Tecnológica – plano
que multiplicou o número de Institutos Federais em todo o território nacional – o
Instituto Federal de São Paulo executava todo o processo de avaliações quase que
de forma manual, contando apenas com os programas Microsoft Word (para montar
relatórios) e Microsoft Excel (para controlar prazos). Entretanto, após o Plano de
Expansão, essa situação tornou-se insustentável, visto que o número de
contratações cresceu muito.
Então, para suprir essa necessidade de organizar dados, foi que se passou a utilizar
o Microsoft Access.
12. REFERÊNCIAS
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. BANCOS DE DADOS:
APRENDA O QUE SÃO, MELHORE SEU CONHECIMENTO, CONSTRUA OS
SEUS. São Paulo: Edgard Blücher, 2005.