Banco de Dados - Princípios e Prática

banco_de_dados...

...princípios_e_prática_

diretor presidente_Wilson Picler

conselho editorial_Ivo José Both, Dr. (presidente) _Elena Godoy, Drª.

_ José Raimundo Facion, Dr.

_Sérgio Roberto Lopes, Dr.

_Ulf Gregor Baranow, Dr.

supervisão editorial_Lindsay Azambuja, M.e

análise de informação_Adriane Ianzen

revisão de texto_Sandra Regina Klippel

capa_Denis Kaio Tanaami

projeto gráfico_Raphael Bernadelli

diagramação_Regiane de Oliveira Rosa

Rua Tobias de Macedo Junior, 319

Santo Inácio_CEP 82010-340_Curitiba_PR_Brasil

Informamos que é de inteira responsabilidade do autor a emissão de conceitos.

Nenhuma parte desta publicação poderá ser reproduzida por qualquer meio ou forma sem a prévia autorização da Editora Ibpex. A violação dos direitos autorais é crime estabelecido na Lei nº 9.610/98 e punido pelo artigo 184 do Código Penal.

M488b Medeiros, Luciano Frontino de

Banco de dados : princípios e prática / Luciano Frontino de Medeiros – Curitiba: Ibpex, 2007.

186 p. : il.

ISBN 978-85-87053-89-2

1. Banco de dados. 2. Tecnologia da informação. 3. Informática. I. Título.

CDD 005.74 20.ed.

apresentação_

Este livro conta com o apoio da Faculdade Inter-nacional de Curitiba (Facinter) e da Faculdade de Tecnologia Internacional (Fatec), ambas institui-ções do Grupo Uninter, como obra a ser consul-tada nas disciplinas e nos módulos referentes a bancos de dados nos cursos da área de tecnologia em informática e análise de sistemas.

A presente obra procura fazer uma ponte entre a área de banco de dados e os conceitos de

siste-mas de informação, buscando agregar um sentido maior à necessidade de informações no desempe-nho das atividades de uma organização. A idéia também foi a de não nos atermos a uma imple-mentação específica de banco de dados, mas ten-tar apresenten-tar de forma genérica o padrão SQL em si e resumir todos os comandos abordados nas seções do capítulo 4 e 5 no apêndice B. Assim o

livro apresenta a possibilidade de servir, inclusive, como um manual de consulta para comandos. O modelo E-R (Entidade-Relacionamento) é des-crito em capítulo específico. Isso porque tais con-ceitos permitem o tratamento dos dados e de suas relações sob um contexto semântico (concedendo um maior sentido às representações de dados do que o modelo relacional utilizado genericamente). Esse modelo foi explorado aqui de conformidade com a literatura existente na área através de uma abordagem bastante prática. Tal conceito pode servir de suporte a pesquisas mais detalhadas, em seu âmbito de aplicação, inclusive como comple-mento ao estudo de ontologias em representação do conhecimento.

Os capítulos apresentam ao final uma série de exercícios para fixação dos conteúdos pertinen-tes, realizando explicações referentes à parte con-ceitual, bem como à parte prática de banco de dados. Alguns exemplos trazem atributos sem a acentuação usual da língua portuguesa, pois leva-mos em consideração que no padrão SQL e nas implementações de bancos de dados não são per-mitidos caracteres acentuados.

sumário_

0000_0001 = I = introdução_ao_banco_de_dados = 11 0000_0010 = II = o_modelo_entidade-relacionamento_(E-R) = 33 0000_0011 = III = álgebra_relacional = 64 0000_0100 = IV = standard_query_language_SQL = 93 0000_0101 = V = modifi cações_no_banco_de_dados = 145 referências_por_capítulo = 157 referências = 159 apêndices = 161 anexo = 181

introdução_

Este material surgiu da compilação de várias notas de aulas e de exercícios praticados com alu-nos das disciplinas de Banco de Dados I e II minis-tradas na Faculdade Internacional de Curitiba no período entre 2002 e 2004. A abordagem pro-cura ser simples, com ênfase em comandos SQL, de acordo com o padrão, ao que adicionamos os conceitos de álgebra relacional e fazemos um paralelo entre as duas linguagens de consulta ao longo de todo o conteúdo.

Considerando que o banco de dados se consti tui no elemento chave para a adequada repre sen tação da informação e do conhecimento, o con teúdo descrito nesta obra objetiva auxiliar o leitor já consciente de certos conceitos da área de infor-mática – e inclusive aqueles com um grau inicial de prática – a aprofundar-se em aspectos teóricos de modelagem de dados e de linguagens de consulta.

A área de banco de dados dá suporte a uma série de disciplinas, envolvendo programação e desen-volvimento de sistemas, e, também, subsídios para o estudo de áreas mais avançadas, como a cons-trução de Data Warehouses e a mineração de dados. Portanto, é de esperar-se que o leitor possa enri-quecer mais seus conhecimentos nessa área. Este livro, portanto, destina-se àqueles usuários com certos conhecimentos e prática em banco de dados. O conhecimento de SQL é comparado com a abordagem simbólica da modelagem E-R e a linguagem da álgebra relacional. Propõe-se tanto como literatura adicional ou complemen-tar para disciplinas de banco de dados e àquelas correlatas em cursos de graduação e pós-gradua-ção, além de ferramenta de auxílio a profissionais desse campo de atuação.

introdução

ao_banco

de_dados_

Os sistemas de informação

estão na atualidade pro-fun damente arraigados nas empresas. Estamos na era da informação, portanto não poderia ser diferente. Uma empresa tem seu grau de competitividade proporcio-nal à importância que a mesma – repre-sentada pelos seus dirigentes, executivos e colaboradores – dá à informação. As infor-mações são as “molas-mestras” para a tomada de decisão, e uma decisão errônea pode acarretar sérias conseqüências ao desempenho da empresa como um todo. A busca de qualidade de informação deve, então, ser uma constante no dia-a-dia das organizações, e ao armazenamento e processamento adequado de

infor-mação é atribuído um papel fun-damental no âmbito de um

sistema de informação. A evolução da informática permitiu uma grande mudança nos paradig-mas organizacionais. Uma grande empresa pode, atualmente, empre-gar seus esforços de crescimento e desenvolvimento apenas em função da internet* relacionando-se com seus clientes e fornecedores apenas por este meio. Hoje, as empresas fazem seus negócios de forma virtual e

* Como, por exemplo, o caso da livraria virtual Amazon Books. Para mais informações acesse: http://www.amazon.com

divulgam os seus produtos a uma massa globalizada de consumidores, portanto os sistemas de informação tornaram-se vitais como suporte para tal situação. Isso fez com que a necessidade de processos de bancos de dados eficientes e eficazes ficasse cada vez mais evidente.

Mas o que são efetivamente bancos de dados? Date1 _{afirma que “um} banco de dados é uma coleção de dados persistentes utilizada pelos sistemas de aplicação de uma empresa”, sendo a persistência entendida como os dados que são diferentes daqueles que têm características efême-ras, e que apenas podem ser removidos por alguma solicitação explícita externa. Grassmann e Tremblay2 _{dizem que os atributos ou itens que} des-crevem entidades do mundo real, tal como uma pessoa, coisa ou evento, são estruturados em registros que, por sua vez, compõem os arquivos. Se o conjunto destes é utilizado por programas ou aplicações em certa área de uma empresa, então, a esse conjunto denominamos de banco de dados. Turban, Rainer Júnior e Potter3 _{conceituam banco de dados como sendo} um grupo lógico de arquivos relacionados entre si, armazenando dados e associações entre eles, para evitar uma variedade de problemas asso-ciados a um ambiente tradicional de arquivos. Em Laudon e Laudon4_, temos caracterizado o aspecto hierárquico envolvido na organização de um banco de dados, indo desde o bit que se agrupa em bytes, os quais, por sua vez, compõem os campos. Os campos constituem um registro. Vários registros produzem finalmente um arquivo – o conjunto destes

arquivos forma o banco de dados. É, ainda, O’Brien5 _{que se refere ao} banco de dados como “um conjunto integrado de elementos de dados

relacionados logicamente”.

Baseando-nos nisso, podemos conceituar banco de dados (ou, abreviadamente, BD) como sendo um conjunto de dados com

15

certa organização característica, com o objetivo de armaze-namento persistente dos dados e dotado de mecanismos de manipulação para obtenção de informações e recuperação posterior, dentro de um sistema de informação.

O banco de dados vem a ser uma representação dinâmica, visto que os dados podem sofrer alterações temporais. Podemos dizer que o BD procura ter em sua representação uma “imagem” de uma situação do mundo real constituída de objetos, das relações entre esses objetos e de eventos. A partir dessa imagem, o BD, então, tem condições de fornecer informações, evidenciando situações que podem ter importância para um processo de tomada de decisão, pois os dados podem ter represen-tações diversas para uma mesma situação.

É necessário que um BD tenha uma representação eficiente que possi-bilite acesso a informações corretas, em tempo hábil. Além disso, cer-tos princípios devem ser levados em conta para se obter um BD eficiente. São eles: redundância, inconsistência e integração.

1. Redundância: o armazenamento dos dados de determinada empresa, ao longo de suas atividades, pode tender à redundância, ou seja, setores que dependem de informações comuns podem fazer a guarda dos mes-mos dados simultaneamente. A falta de cuidado na análise do sistema de informações pode acarretar em redundância, incorrendo em custos de armazenamento.

2. Inconsistência: os dados armazenados referentes à determinada situ a -ção que apresente a possibilidade de sofrer alterações ao longo do tempo necessitam de atualização, uma vez que dados desatualizados podem gerar inconsistência de representação. Outro fator que também pode acarretar inconsistência é a redundância, pois dados armazenados em

locais diferentes podem sofrer alterações diferenciadas no transcorrer do tempo. A inconsistência, por sua vez, pode gerar tomada de decisões defasadas ou errôneas.

3. Integração: os dados existentes em um BD geralmente são compar-tilhados por várias pessoas ou setores em uma empresa. Assim surge a necessidade de integração, estabelecendo-se procedimentos para o acesso em vários níveis com a contínua atualização dos dados, de forma a manter a “imagem” do mundo real única e evitar ruídos na comuni-cação entre setores.

[

breve histórico

]

Em termos de histórico de BD, podemos dizer que a forma de armaze-namento físico dos dados está associada, desde o princípio da compu-tação, aos meios de gravação existentes. Os primeiros computadores, comercializados nas décadas de 1950 e 1960, tais como o Univac ou os modelos IBM, utilizavam unidades seqüenciais de fita para gravação per-manente dos dados6_{. Nesse período, a recuperação das informações era} feita de maneira também seqüencial.

Em termos de armazenamento lógico, as primeiras linguagens de progra-mação implementavam funções e procedimentos de acesso aos dispositivos para gravação e leitura dos dados, não caracterizando um sistema próprio de banco de dados, sendo manipulados diretamente pelos siste mas desen-volvidos. Assim, linguagens como Assembler e Cobol possuíam direto, em seu conjunto de comandos, o acesso aos dados; o que permitia aos siste-mas trabalhar com estruturas e operações primitivas para manipulação. Podemos de certa forma resumir o histórico de BD em cinco fases distintas que passaremos a detalhar na seqüência.

17

1. A primeira fase surgiu com o advento das primeiras linguagens de pro-gramação pela necessidade de armazenagem dos dados processados na memória de forma permanente. Os primeiros computadores possuíam unidades de fita magnética que gravavam os dados de forma seqüencial, assim as primeiras linguagens trabalhavam com procedimentos ou fun-ções embutidos no seu código, de forma que o programador tinha que desenvolver, além do próprio sistema ou aplicativo, os procedimentos para gravar ou ler dados do meio permanente.

2. A segunda fase, na década de 1970, caracterizou-se pelo surgimento de linguagens que traziam bibliotecas específicas para acesso a dados permanentes. Tal como a linguagem C – desenvolvida, em 1974, por Kernigham e Ritchie – que trabalhava com o conceito de cabeçalhos-padrão*. Porém, a especificação dos arquivos não seguia um padrão ou formato predeterminado, sendo que os aplicativos ainda tinham a sua metodologia de acesso a dados permanentes de forma customizada. Não obstante, os primeiros modelos de bancos de dados relacionais sur-giram naquela época com a pesquisa inicial de Codd**. A preocupação de Codd embasava-se na independência dos dados e na proliferação de tipos de dados em aplicações que ocasionavam inconsistências 7_.

3. Na terceira fase, final da década de 1970 e início de 1980, apareceram as primeiras padronizações para acesso a dados. As companhias de software forneciam junto com os pacotes de linguagem de programação o software responsável pelo tratamento de BD, com formatos de arquivo padroniza-dos e linguagem específica de acesso. Tais sistemas foram chamapadroniza-dos de

* Alguns desses cabeçalhos tratavam de especificar os tipos e funções para tratamento de arquivos.

** E. F. Codd foi um pesquisador britânico que publicou as primeiras contribuições para a teoria dos bancos de dados relacionais, enquanto trabalhava para a IBM.

sistemas de gerenciamento de banco de dados – SGBD, que trabalhavam proporcionando à linguagem os meios para acesso a BD. Os SGBD fun-cionavam como entidades separadas do sistema, permitindo que funções de armazenamento e recuperação de dados pudessem ser feitas em seu próprio domínio de gerenciamento. Porém, tais softwares de SGBD esta-vam ainda restritos ao ambiente de programação do fabricante.

4. Na quarta fase, advinda no final da década de 1980 e início da década de 1990, os SGBD foram tratados como softwares autônomos, sendo comercializados separadamente das linguagens de programação ou dos ambientes de desenvolvimento. O sistema operacional fornecia o padrão de comunicação entre o software e o SGBD. Nessa fase, um padrão de lin-guagem universal de acesso a BD, o Standard Query Language – SQL surgiu e permitiu que os fabricantes de SGBD fornecessem interfaces de acesso de forma declarativa. Assim a evolução da metodologia de programa-ção e a sistematizaprograma-ção do acesso a BD permitiram a separaprograma-ção entre o progra ma em si e os procedimentos de manipulação de BD.

5. É possível ainda citarmos uma quinta fase, na qual podemos inserir modelos avançados como BD orientados a objeto, os conceitos de BD distribuídos, além da aplicação de aspectos de Inteligência Artificial – IA a BD, como mineração de dados, data warehouses e sistemas de desco-berta de conhecimento – KDD (Knowledge Discovery Data). Para mais deta-lhes sobre a história da computação, sugerimos as obras de Meyer8 _{e para} aplicações de banco de dados e novas tendências, Elmasri9 _{e Date}10_.

[

hierarquia do conhecimento

]

Do ponto de vista puramente físico, um arquivo nada mais é do que uma seqüência de 0´s e 1´s gravada em um meio de armazenamento estático.

19

A seqüência de bits é ininteligível do ponto de vista do tratamento com os dados, considerado, esse, o primeiro nível ou o mais baixo no trata-mento de dados na hierarquia do conhecitrata-mento.

Num segundo nível, quando consideramos uma seqüência de 8 bits, podemos identificar um dígito ou caractere Ascii* e, assim, a informa-ção começa a fazer um certo sentido. Em vez de 0´s e 1´s, temos agora seqüência de caracteres padrões codificados de 8 em 8 bits.

No exemplo (Figura 1.1), a seqüência de bits 01100001 corresponde ao número 61 hexadecimal ou 97 decimal. Pela tabela Ascii**, o 97 corres-ponde ao caractere ‘a’.

Figura 1.1 – Seqüência de bits / dígito Ascii

0 1 1 0 0 0 0 1 → 61 → 97 → a

As seqüências de dígitos ou caracteres agrupadas, num terceiro nível, formam os dados (Figura 1.2). Caso tal agrupamento seja quebrado, perde-se o sentido do mesmo. Podemos dizer que, dessa forma, temos os dados caracterizados como “átomos”, em termos de indivisibilidade. O nome próprio de uma pessoa (vamos exemplificar com MARIA) não fará nenhum sentido se for separado em duas partes (MAR e IA).

Figura 1.2 – Seqüência de dígitos Ascii

P a r a f u s o

* Ascii: sigla de American Standard Code for Information Interchange, que se constitui em um código numérico usado para representar os caracteres e é entendido por quase todos os computadores. ** Um modelo de “tabela Ascii” pode ser visto no anexo desta obra.

Os dados isolados, no entanto, não identificam bem elementos ou enti-dades da vida cotidiana que necessitamos trabalhar, quando dados de diferentes naturezas precisam ser armazenados, como o endereço de um cliente (nome, endereço, complemento, cidade, estado, CEP), o saldo de uma conta bancária (cliente, conta, débito, crédito) ou a quantidade fabricada em uma linha de produção (produto, código, quantidade, custo). Dessa forma, num quarto nível temos os dados ou átomos agru-pados – mesmo chamando tais grupos de “moléculas” –, possibilitando que mais tarde, em conjunto ou em confrontação com outros conjuntos de dados e a transformação dos mesmos, venham a produzir o que cha-mamos de “informação”.

A informação, que podemos considerar o quinto nível, diz respeito a algo novo, a partir do sentido isolado dos dados ou átomos e de grupos de dados inseridos num certo contexto. Já os arquivos com a caracterís-tica de um BD referem-se a uma seqüência de dados ou átomos de dife-rentes naturezas (Figura 1.3), armazenados conforme uma disposição pré-definida muitas vezes denominada de cabeçalho ou estrutura.

Figura 1.3 – Seqüência de dados

nome endereço telefone cidade salário

Maria Rua das Camélias 3222-3300 Curitiba 2.500,00

Assim, ao especificarmos a informação como o quinto nível da hierarquia, o acervo formado pela geração de informações nos processos de gestão, devidamente filtradas e sistematizadas ao longo do tempo em um certo ambiente, tal como um sistema de informação de uma empresa, constitui o conhecimento que compõe, dessa forma, o sexto nível da pirâmide. Podemos, ainda, elaborar um sétimo nível, onde o conhecimento gerado pelas informações, sendo manipulado por pessoas ou sistemas com vistas

21

a atender certos objetivos, constitui a inteligência. Neste último nível da hierarquia de conhecimento, o processo de tomada de decisão faz uso de todo o edifício elaborado, desde a estrutura simplificada dos bits até a ponte com o pensamento humano ou mesmo de um agente de soft ware utilizando inteligência artificial.

Observamos, portanto, que dentro dessa pirâmide, os processos de BD representam um importante fundamento aos procedimentos de mais alto nível necessários para a vida das organizações.

Existe uma série de representações da hierarquia do conhecimento. O lei-tor pode obter mais pesquisando, por exemplo, sobre sistemas de conhe-cimento em Rezende11_{, e sobre introdução à gestão do conhecimento em} Turban, Rainer Júnior e Potter12_.

Figura 1.4 – Representação da hierarquia do conhecimento

Grupos de Dados / Moléculas Informação Conhecimento Inteligência Dados / Átomos Dígitos Bits

[

registro, atributo, campo, item e tabela

]

Ampliando o conceito de cabeçalho ou estrutura, fornecidos no tópico anterior, a melhor maneira de visualizarmos um registro é através de uma lista ou relação.

Numa lista, os dados referentes a certo contexto serão colocados em colunas, um abaixo do outro, e as colunas dos dados de diferentes natu-rezas são colocadas uma ao lado da outra.

Como exemplo, a lista a seguir consta de quatro colunas. A primeira refere-se a um número seqüencial, a segunda ao nome de um produto, a terceira à quantidade do mesmo e a quarta ao valor referente ao custo de fabricação. Logo os dados referentes a cada um dos registros têm naturezas diferentes, e na primeira linha, estão os nomes das colunas.

Figura 1.5 – Exemplo de lista ou tabela

codigo nome quantidade custo

1 Parafuso 1.000 0,05

2 Chave de fenda 20 4,50

3 Prego 2.000 0,02

O registro é identificado como uma linha da lista, com conteúdo em cada tipo de dado representado pela coluna. Temos, então, três regis-tros nessa lista. A primeira coluna identifica o código de cada um dos registros de forma numérica e seqüencial.

A lista é denominada de tabela e possui um nome ou identificador próprio. Um banco de dados de certo sistema pode ser constituído de várias tabelas, e estas possuem uma estrutura padronizada composta por atributos ou campos: código, nome, quantidade e custo. Esse con-junto de atributos ainda é referenciado como o esquema da tabela. Cada valor em um registro referente a um atributo ou campo é denomi-nado de item de um registro.

Ilustramos, a seguir, o armazenamento físico dos dados acima em ter-mos de bytes:

23

Figura 1.6 – Armazenamento físico de dados

0 0 0 1 P a r a f u s o 0 0 3 E8

0 0 0 0 5 0 0 0 2 C h a v e d e F e n d a

0 0 0 20 0 0 0 4 32 0 0 0 3 P r e g o

0 0 7 D0 0 0 0 0 2

Desde que consideremos para nomes os campos com 15 bytes, campos numéricos inteiros com 4 bytes e campos de números de moeda com 5 bytes, a representação física (apenas dos dados), que você viu acima, pode ser considerada. Notamos, ali, que os dados estão dispostos como numa fila de bytes. O tamanho total em bytes do registro que estamos considerando é de 28 (dois campos numéricos inteiros de 4 bytes, um campo string* de 15

bytes e um campo moeda de 5 bytes). É importante verificar que os valores

inteiros são convertidos na representação hexadecimal para depois serem armazenados. Com 4 bytes, e cada bit guardando um número na faixa de 0 a 255, existe a possibilidade de guardar valores inteiros positivos numa faixa de 0 a 4.294.967.296 (considerando números cardinais ou não-nega-tivos). Assim, no primeiro registro o número 1.000 (em hexadecimal 3E8) é armazenado em 2 bytes e com os outros 2 contendo zeros: 00 00 03 E8. A seguir, temos a representação da fila de bytes convertidos em caracte res

Ascii hexadecimais.

Figura 1.7 – Bytes convertidos em caracteres Ascii

0 0 0 1 50 61 72 61 66 75 73 6F 20 20 20 20 20 20 20 0 0 3 E8

0 0 0 0 5 0 0 0 2 43 68 61 76 65 20 64 65 20 46 65 6E 64 61

20 0 0 0 14 0 0 0 4 32 0 0 0 3 50 72 65 67 6F 20 20 20 20

20 20 20 20 20 20 0 0 7 D0 0 0 0 0 2

Desse modo, cada caractere é convertido em seu correspondente hexa-decimal Ascii, quando consideramos strings. Em geral, os campos string em BD correspondem a itens com tamanho máximo de 255 caracteres, embora possam ser variáveis em outros casos.

No exemplo anterior, devemos considerar que manipulamos uma estru-tura de registro de tamanho fixo, ou seja, todo e qualquer registro gra-vado no arquivo sempre terá um tamanho de 28 bytes. Se quisermos identificar onde começa o segundo registro, é só nos deslocarmos até a posição 29 do arquivo, pois os próximos 28 bytes referem-se a ele. Ou, então, de forma genérica, se quisermos saber onde começa o registro n, basta fazermos np + 1, onde p é igual ao tamanho do registro.

Na maioria dos sistemas de BD atuais, trabalhamos também com o conceito de registro de tamanho variável, sendo que os espaços em branco (caractere Ascii 20) são suprimidos, permitindo, dessa maneira, um aproveitamento maior do dispositivo de armazenamento.

O conceito de registro está presente nas linguagens de programação, representando uma estrutura de dados heterogênea, ou seja, composta de vários tipos. Se quiséssemos expressar em linguagem Pascal, por exemplo, a definição da estrutura acima colocada, poderíamos ter na cláusula type, no início de uma unit, a definição de um record, seguido de uma declaração de variável na cláusula var:

type PRODUTO = record Codigo: integer; Nome: string; Quantidade: integer; Custo: real; end; var PROD: PRODUTO;

25

Podemos dizer que o código acima trabalha com o modelo lógico de registro. Caso queiramos ler um arquivo com essa estrutura, precisamos de um procedimento especial, montado de forma a ler o conteúdo do arquivo. Uma proposta para isso é:

Procedure Ler; Var F: File; Begin

Assign(F, ’PRODUTO’); Reset(F);

While Not Eof(F) Do Begin ReadLn(F, Prod); Write(Prod.Codigo); Write(Prod.Nome); Write(Prod.Quantidade); Write(Prod.Custo); WriteLn; End; Close(F); End;

O que podemos entender do algoritmo colocado acima é que cada registro é lido dentro do loop while e mostrado na tela. Ou seja, é necessá-rio especificar todo o procedimento preciso para listarmos o conteúdo do arquivo ou seus registros.

As metodologias utilizadas atualmente em softwares de BD permitem que tal esforço seja economizado em termos de programação; pois, desde que fornecidas as interfaces adequadas, o processo inteiro de uma listagem ou consulta (no inglês, query) pode ser obtido com apenas uma declaração SQL simples.

Podemos, assim, enviar o seguinte comando, para uma interface de um SGBD, desde que a estrutura da tabela (o modelo lógico) esteja criada:

SELECT * FROM produto;

Após a execução, obtemos o resultado da consulta já formatado, como na figura a seguir.

Figura 1.8 – Resultado da consulta

codigo nome quantidade custo

1 Parafuso 1.000 0,05

2 Chave de Fenda 20 4,50

3 Prego 2.000 0,02

O comando SELECT indica que está sendo feita uma consulta, o aste-risco indica que devem ser listados todos os atributos ou campos e a cláusula FROM seguida do nome da tabela PRODUTO indicam a ori-gem dos dados. Portanto, como você percebeu, não é necessário forne-cer nenhuma informação a respeito do tipo dos dados que queremos, nem do tamanho de cada um, nem mesmo interessa como os dados são guardados.

[

sgbds e sistemas de informação

]

Como foi visto anteriormente, um SGBD é o responsável por todas as tarefas pertinentes ao armazenamento, à recuperação, à segurança e ao gerenciamento dos dados.

Na atualidade, podemos verificar a existência de vários SGBDs no mer-cado. Um sistema de informação é desenvolvido de forma conjunta com um SGBD, pois, enquanto um sistema de informação está encarregado do processamento da informação em si, o SGBD tem a tarefa do geren-ciamento da armazenagem da informação.

A partir de um modelo de dados requisitado* para o suporte a um sistema de informação, qualquer SGBD deve ser capaz de permitir a implementação

* Tal modelo de dados pode ser obtido através do uso de ferramentas CASE – Computer-Aided Software Engineering.

27

desse modelo em um conjunto de estruturas, bem como permitir modifi-cações e consultas eficientes aos dados armazenados.

Os SGBDs fornecem uma interface de conexão ao banco de dados, a qual permite a comunicação do sistema de informação com o mesmo. Nesse processo de conexão, um usuário requisita os processos de um sistema de informação, este, em função disso, interage com o SGBD emitindo solicitações de consultas ou modificações, e o SGBD retorna os dados necessários.

Além da interação com o usuário, durante a atividade de desenvolvi-mento de um sistema de informação, que pode ser feito numa ferra-menta RAD*, a interface permite o acesso aos dados em tempo real, otimizando bastante o processo de desenvolvimento.

Com o advento da internet, os sistemas de informação romperam a barreira das redes locais e internas das empresas para disponibilizarem informações de forma global na web. Qualquer cliente de uma empresa pode acessar a página da mesma e comprar produtos remotamente, em qualquer parte do mundo. Os SGBDs foram, portanto, adaptados para contemplarem essa possibilidade de conexão de bancos de dados com sistemas na web.

A operação de tais sistemas – seja em redes intranet, seja extranet ou, ainda, internet – ficou facilitada para os usuários e permitiu grande eco-nomia para as companhias em função da diminuição da redundância. Empresas com filiais ao redor do mundo podem compartilhar dados a partir de um único local físico, onde se encontram os servidores.

* Rapid Application Development, tais como o Delphi (Borland) e Visual C ou Visual Basic (Microsoft).

O advento da internet também influiu no desenvolvimento de SGBDs mais seguros e confiáveis, visto que as páginas colocadas na web têm visi-bilidade irrestrita, ou seja, podem ser acessadas por qualquer pessoa, o que corresponde ao que desejam as empresas, pois procuram maximizar a aquisição de mais clientes em suas operações.

Com a difusão dos sistemas de informação em variadas plataformas, desenvolvidos em ferramentas Case ou em ambientes de desenvolvi mento diversos – suportados por SGBDs de diferentes fabricantes –, a profusão de dados é exponencialmente grande e ainda continua crescendo. A aquisição de novos sistemas por parte de uma empresa, com novas tecnologias em relação ao que ela já possui, faz com que, na maior parte das vezes, ela compartilhe diferentes sistemas de informação em um mesmo período de tempo. Costuma-se denominar os sistemas antigos e existentes na empresa como sistemas legados. Para que os diferen-tes sistemas de informação compartilhem uma mesma base de dados, é necessário conjugar os diferentes SGBDs ou mesmo pastas de tabelas em arquivos em um único local. Em certas situações, é até possível con-siderar a redundância em certos conjuntos de dados, que poderão ser tratados e filtrados mais tarde*.

Em relação a essa situação, o conceito de data warehouse atende a expec-tativa, no sentido de agrupar uma grande quantidade de dados loca-lizados em diferentes fontes (inclusive fisicamente distantes) em um único repositório. Os data warehouses, de acordo com a conceituação de Inmon13_{, são um conjunto de dados granulares integrados, armazenando}

* Tal tratamento pode ser a uniformização de dados, como, por exemplo, gravar todos os nomes de clientes em caixa-alta, sempre separar o código postal com um hífen etc., dependendo da defini-ção da forma de armazenagem dos dados. Diz-se também que os dados em um data warehouse podem estar não-normalizados.

29

e gerenciando os dados em um certo período de tempo, que podem ser resumidos ou agregados para a criação de novas formas de dados. A partir da formação de um data warehouse, que disponibiliza, por sua vez, uma grande quantidade de dados, fica possível por parte da empresa a busca de certas informações referentes a padrões nos dados que se repitam num certo período de tempo.

Por exemplo, pode ser constatado, num sistema de CRM*, um padrão de comportamento de um certo grupo de clientes, numa faixa etária bem definida, que compram determinado produto em um período específico de tempo. Tal informação pode ser útil para que a empresa defina políticas de marketing direcionadas para esse grupo de clientes**. É importante ressaltar que tal padrão é invisível em primeira mão, não pode ser captado simplesmente a partir das funções específicas do sis-tema de informação, mas apenas após seu agrupamento em um repo-sitório (via data warehouse) e abarcando por sua vez um grande período de tempo. Isso permite, então, a identificação sistemática de padrões subjacentes aos dados, e tal processo consiste nos procedimentos da mineração de dados ou data mining.

“No data mining, os dados de um data warehouse são processados para identificar fatores e tendências-chave nos padrões das atividades de negócios”14_{, segundo afirma O’Brien, pois a mineração de dados} cons-titui-se e de diferentes técnicas que podem ser aplicadas a um conjunto de dados para a extração de padrões. Assim, embora a mineração de

* Sigla de Customer Relationship Management, um sistema com o objetivo de gerir relacionamentos da empresa com seus clientes. ** O clássico que se refere à correlação entre a compra de fraldas e

de cervejas, que acontece em supermercados, próximo ao final de semana, é um ótimo exemplo de identificação de padrão.

dados seja um campo relativamente novo na área de ciência da compu-tação, pode possibilitar às empresas a identificação de boas oportuni-dades de negócios a partir dos dados armazenados em seus SGBDs.

[

resumo

]

Banco de dados, podemos, portanto, conceituar como sendo conjun-tos de dados com certa organização definida, dotado de procedimen-tos para manipulação dos dados e com o objetivo de armazenamento e posterior recuperação de dados. Em relação ao desenvolvimento do BD, consideramos alguns aspectos fundamentais e os sintetizamos a seguir.

Nesse processo, três princípios devem ser levados em conta: redun-_

dância, inconsistência e integração.

Em termos de histórico é possível enumerarmos cinco fases da evolução _

dos BD, desde o seu início até os dias atuais; já na hierarquia do conhe-cimento, podemos mostrar como os bits transformam-se em dados e conhecimento até chegar ao nível da “inteligência” das empresas. Outros conceitos importantes são registro, item de registro, campo _

ou atributo, tabela e esquema.

Os registros podem ser de tamanho fixo ou variável e, ainda, serem _

descritos em termos de seu armazenamento físico ou mesmo conside-rando o seu modelo lógico.

O uso de linguagens padrão para consultas de BD, como SQL, sim-_

plificam bastante o processo de obtenção ou manipulação dos dados em um SGBD.

31

SGBDs trabalham em conjunto com sistemas de informação, forne-_

cendo a conexão aos dados e às ferramentas de suporte da gestão dos dados.

A internet permitiu aos SGBDs adaptarem-se às novas possibilidades _

de sistemas de informação via web, mas também evidenciou certas necessidades de segurança.

Data warehouses

_ são importantes para a unificação de sistemas novos e legados, e podem ser o início da adoção de processos de data mining por parte de uma empresa, para a identificação de padrões ocultos e repetitivos no tempo.

[

exercícios

]

1. Defina banco de dados.

2. Cite os princípios que devem ser considerados para termos um BD eficiente e dê um exemplo real do impacto de um deles.

3. De que forma trabalhavam as primeiras lingua-gens em termos de manipulação dos dados? 4. O que é um SGBD?

5. Faça um resumo sobre a hierarquia do co nhe -cimento.

6. Conceitue registro.

7. Conceitue atributo ou campo. 8. Conceitue item de registro.

9. Conceitue tabela.

10. Diferencie registros de tamanho fixo e variável. 11. Por que é mais simples usar uma consulta SQL em vez de um algoritmo para ler dados em um arquivo/tabela?

12. Qual o impacto do advento da internet sobre os SGBDs?

13. O que é data warehouse?

14. Descreva uma situação em que certo tipo de dado precisa ser uniformizado em um data warehouse. 15. O que é data mining?

16. Dê um exemplo de um padrão repetitivo subja-cente de dados.

o_modelo

entidade-relacionamento

(E-R)_

Em 1976, Chen introduziu

a idéia de um modelo de entidade-relacionamento para representar bancos de dados1_{. O} modelo baseia-se em uma descrição dos dados com maior ênfase nos aspectos semânticos de representação, não sendo necessário compreender o modelo lógico

sub-jacente. Os modelos ao longo dos anos sofreram variações2_{, porém o modelo de Chen é um dos} mais difundidos. Apesar do modelo

enti-dade-relacionamento (ou modelo E-R) não ser implementado em SGBDs, tal como o modelo relacional, ele

apresenta um bom ponto de partida para a

compreen-são entre os elemen-tos existentes em um determinado con-texto e as relações entre os mesmos. De certa forma, ele antecede o projeto lógico que pode ser feito em um modelo relacional, o qual através de regras para conversão pode ser montado a partir de um diagrama E-R, desde que este esteja bem definido. Os sistemas de BD, em geral, não possuem uma “compreensão” esten-dida do significado de certos valores de atributos. Tipicamente, os BD têm apenas uma compreensão limitada a certos valores atômicos sim-ples e alguns vínculos de integridade simsim-ples aplicados a esses valo-res, mas qualquer interpretação adicional tem que ser dada pelo ser humano. Como exemplo, seria interessante se numa consulta ao BD

pudesse ser entendido que pesos de peças e quantidades de remessas, embora sejam ambos valores numéricos, são de espécies diferentes, ou seja, semanticamente distintos. Portanto uma comparação direta entre peso e quantidade deveria ao menos ser questionada, se não rejeitada de todo pelo modelador.

Passaremos agora aos conceitos envolvidos com a abordagem E-R para modelagem de bancos de dados. Durante a exposição do conteúdo, daremos preferência à abordagem de design e de modelagem de enti-dade-relacionamento encontrada em Heuser3_.

[

entidade

]

Entidades são elementos ou objetos perfeitamente distinguíveis. No processo de modelagem E-R, as entidades são os primeiros elementos a serem considerados por estarem explícitos ou evidentes.

Esses elementos podem ainda representar algo concreto – como, por exemplo, uma pessoa ou um produto – ou abstrato – tal como uma data ou mesmo uma seção de uma empresa.

Uma entidade também pode ser vista como sendo pessoal (empregado, funcionário), local (endereço, cidade, estado), objeto (produto, maté-ria-prima), evento (venda, registro, cadastramento) ou entidade

con-ceitual (seção, conta). A representação é feita através de retângulos (Figura 2.1) contendo no seu interior o nome das entidades.

Figura 2.1 – Representação de entidades FUNCIONÁRIO PRODUTO SEÇÃO

37

Assim, quando simbolizamos a entidade “funcionário”, não quer dizer que se trata de um funcionário específico, mas de um conjunto de funcio nários, portanto ela pode ser valorada pelos elementos do con-junto que representa. Contudo, quando falamos de um elemento ou dado referente a uma entidade, diz-se que tal dado representa uma

ins-tância desta entidade. Por conseguinte ainda que tenhamos outros con-ceitos, que são vistos adiante, envolvidos com a abordagem E-R, como

atributos, relacionamentos e subtipos; tais conceitos devem ser vistos como propriedades das entidades, as quais são assumidas conforme a necessidade da modelagem E-R.

[

atributos

]

Atributos são as características de uma entidade. Eles podem ter uma faixa de valores ou de domínio e, ainda, caracterizarem-se por serem atômicos (simples) ou não-atômicos (compostos). Assim, apesar da possibilidade de fazermos o contrário, devemos sempre procurar cons-truir atributos simples.

Podemos, inclusive, ter atributos identificadores ou, então, chaves que indiquem uma entidade sem ambigüidade, bem como atributos básicos ou derivados, como por exemplo, a quantidade total para um determi-nado produto ser resumido a partir da soma das peças separadamente para este produto.

Date4 _{dá preferência ao uso do termo propriedade em vez de atributo.} A representação de atributos é feita com elipses ligadas à entidade (Figura 2.2) ou com círculos, e a identificação do atributo é colocada ao lado do mesmo.

Figura 2.2 – Representação de atributos FUNCIONÁRIO ENDEREÇO NOME CÓDIGO FUNCIONÁRIO CÓDIGO NOME ENDEREÇO

Os atributos podem ser:

univalorado ou multivalorado:

_ no caso de o atributo assumir um

único valor ou, então, quando assume mais de um valor;

vazio:

_ quando um atributo em determinado momento não assumir um dado específico ou ser desconhecido (semelhante ao valor NULL existente em SQL);

chave ou identificador:

_ um atributo pode unicamente representar

uma instância de uma entidade, situação em que ele é simbolizado como identificador ou chave mediante o nome sublinhado ou com o círculo do atributo preenchido.

[

relacionamento

]

Através de um relacionamento, duas ou mais entidades podem estar associadas, situação em que elas são representadas por losangos ligando uma entidade a outra (Figura 2.3). Portanto um relaciona-mento é uma associação entre entidades, em que as pertencentes a um relacionamento se dizem participantes do mesmo.

39

Figura 2.3 – Representação de relacionamentos

CLIENTE CARTEIRA PEDIDO

Como visto, os relacionamentos podem ter um nome descrito no losango. Nesse exemplo, temos duas entidades envolvidas: “cliente” – repre-sentando o conjunto de pessoas que são vistas como clientes de uma empresa – e “pedido”, sendo este o conjunto de pedidos que são efetua-dos pelo cliente na empresa. O relacionamento denominado “carteira” refere-se à associação de elementos da entidade “pedido” que, por sua vez, estão associados a seus respectivos elementos representados pela entidade “clientes”.

Quanto aos relacionamentos, podemos considerar a cardinalidade, o tipo de relacionamento e a obrigatoriedade de participação. Heuser exemplifica também relacionamentos sem nomes explícitos5_.

Cardinalidade

A cardinalidade ou multiplicidade define a quantidade de elementos de uma entidade associada com a quantidade de elementos de outra enti-dade. Podemos ter relações de 1:1 (um para um), 1:N (um para N) e N:N (N para N). Por exemplo, a cardinalidade para o relacionamento representado na Figura 2.3 pode ser visto como 1:N, isto é, um cliente pode possuir vários pedidos, porém um pedido pode ser somente de um único cliente.

Figura 2.4 – Representação de relacionamentos e cardinalidade

CLIENTE CARTEIRA PEDIDO 1 N

Na Figura 2.4, vemos, então, que do lado da entidade “cliente” apa-rece o número “1” e do lado da “pedido” apaapa-rece a letra “N”. Para a interpretação da cardinalidade, um artifício que auxilia na identificação da mesma é a elaboração de um diagrama de ocorrências. Num dia-grama de ocorrências, representamos as entidades e relacionamentos, na forma de conjuntos, bem como os elementos pertencentes a cada conjunto. No caso das entidades, representamos os elementos indivi-dualmente e, no caso do conjunto do relacionamento, representamos os pares de elementos associados entre si*.

Figura 2.5 – Diagrama de ocorrências para o exemplo de cardinalidade 1:N

CLIENTE CARTEIRA PEDIDO

c1 c1,p1 p1 c2,p2 p2 c2 c2,p3 p3 c3 c2,p4 p4

Dessa forma, os pares c2, p2 e c2, p3 indicam que um cliente pode possuir mais de um pedido. Porém, não ocorre um par, onde, para um mesmo pedido, tenhamos mais de um cliente.

* Um diagrama de ocorrências, de certa forma, antecipa a visualização de como estariam os dados associados entre si, em termos de um registro, em uma tabela de um banco de dados.

41

No caso de um relacionamento com cardinalidade N:N, entre as enti-dades “funcionário” e “projeto”, denominado “alocação” (veja a Figura 2.6), um funcionário pode estar alocado em mais de um projeto (veja o caso dos pares f2, p2 e f2, p3), e um projeto, por sua vez, pode ter mais de um funcionário (ver os pares f1, p1 e f3, p1).

Figura 2.6 – Diagrama de ocorrências para o exemplo de cardinalidade N:N

FUNCIONÁRIO ALOCAÇÃO PROJETO N N

FUNCIONÁRIO ALOCAÇÃO PROJETO

f1 f1,p1 p1 f3,p1 p2 f2 f2,p2 p3 f2,p3 f3 f3,p4 p4

Para o caso de um relacionamento de cardinalidade 1:1, no exemplo a seguir, temos as entidades “empregado” e “cargo”, e o relacionamento “ocupação” indicando a associação entre as entidades (Figura 2.7). Nesse caso, as ocorrências do diagrama indicam que um empregado pode ocupar apenas um cargo e vice-versa (um cargo não pode ter dois empregados).

Figura 2.7 – Diagrama de ocorrências para o exemplo de cardinalidade 1:1

EMPREGADO OCUPAÇÃO CARGO

1 1

EMPREGADO OCUPAÇÃO CARGO

e1 e1,c1 c1 e2 e2,c3 c2 e3 e3,c4 c3

Quanto à denominação de um relacionamento, não há uma regra para atribuirmos um nome específico. Em vez de “ocupação”, poderíamos denominar de “cargo do empregado” ou “cargo_empregado”.

Tipo de relacionamento

Um relacionamento pode ser, de acordo com o número de entidades que participam na relação, unário, binário ou ternário.

1. O relacionamento binário (associando duas entidades) já foi abor-dado anteriormente, quando da explicação do conceito de relacio-namento, sendo que nos concentraremos agora nos relacionamentos unário e ternário.

2. O relacionamento do tipo unário, é identificado também como um

43

ela mesma. Isso não implica que um registro dessa entidade esteja rela-cionado com ele mesmo.

Vejamos o caso de um produto em fabricação. De acordo com o grau de montagem, um conjunto de peças é montado de forma a produzir uma peça mais complexa, mas que não é ainda o produto final. Essa peça complexa se junta a outras peças ou a matérias-primas, de forma, então, a compor o produto final. Todas essas peças são, aqui, representadas por uma entidade “peça”, sendo o relacionamento denominado “parte de”. O conceito de papel também é importante para a definição de um rela-cionamento unário, para que possamos entender como as instâncias estão associadas. No caso da peça ou peças que “compõem” outra peça, e da peça que é “composta por” outras peças, temos os dois papéis (o do que contém e do que está contido). A definição dos papéis auxilia posteriormente na determinação da cardinalidade do relacionamento. Os papéis devem ser explicitados no diagrama do relacionamento ao lado das ligações. Pela Figura 2.8, vemos que existem os pares p1, p2 e

p3, p2, indicando que a peça p2 é composta pelas peças p1 e p3. Por sua

vez, vemos também que p4 é composta pela peça p2. A cardinalidade N:1 indica que mais de uma peça pode compor outra peça. Essa repre-sentação ilustra bem a estrutura de materiais, também chamada Bill Of

Materials (BOM) para certa linha de produção, o que é necessário em

um programa de Planejamento das Necessidades de Materiais

(Mate-rials Requirement Planning – MRP).

Outros exemplos de relacionamentos unários são os “empregado-che-fia” ou “contas-subcontas” (tal como num plano de contas contábil).

Figura 2.8 – Diagrama de ocorrências para o auto-relacionamento

PARTE_DE PEÇA

Composta por compõem

PEÇA PARTE_DE p1 p2 p4 p3 p1,p2 p2,p4 p3,p2

Figura 2.9 – Exemplo de relacionamento ternário

OCUPAÇÃO

PROJETO

FUNCIONÁRIO _{1 1} ÁREA

N

Um relacionamento ternário implica a associação de três entidades ao mesmo tempo, que pode ser exemplificado por uma associação “funcioná-rio-área-projeto”; desde que um funcionário trabalhe apenas em uma área,

45

porém em mais de um projeto. O relacionamento ilustrado (Figura 2.9) mostra como ficaria esta associação e o relacionamento “ocupação”.

Figura 2.10 – Diagrama de ocorrências para o exemplo de relacionamento ternário

FUNCIONÁRIO PROJETO f1 p1 f2 p2 f1,p1,a2 p3 f3 p4 f2,p2,a1 ÁREA f2,p3,a1 a1 f3,p4,a2 OCUPAÇÃO a2

O diagrama de ocorrências mostra, agora, não mais os “pares”, mas “ternos” ou “triplas” mostrando as instâncias associadas nesse modelo (Figura 2.10). Veja que os ternos f2, p2, a1 e f2, p3, a1 validam a cardina-lidade de 1:1 para a associação “funcionário-área” e 1:N para a asso-ciação “funcionário-projeto”.

É possível, ainda, representarmos relacionamentos contendo mais de três entidades, o que caracteriza relacionamentos quaternários e sub seqüentes.

Obrigatoriedade

Em certos relacionamentos entre entidades podem aparecer situações onde a presença de uma entidade não é obrigatória. Um bom exemplo é o relacionamento “empregado-dependente” na figura abaixo.

Figura 2.11 – Relacionamento empregado-dependente

EMPREGADO FILIAÇÃO DEPENDENTE 1 N

O empregado pode ter dependentes ou não. Para representar isso num diagrama E-R, expandimos o conceito de cardinalidade para mínima e

máxima.

Quando um empregado não possuir dependentes, caracterizamos a _

cardinalidade mínima para 0 (zero) do lado da entidade dependente. Como a entidade empregado sempre participa do relacionamento, a cardinalidade mínima será 1 (um) do lado do empregado.

Quanto à

_ cardinalidade máxima (mantemos o que foi especificado anteriormente), do lado do dependente será N, pois um empregado pode ter vários dependentes. E a cardinalidade máxima para empre-gado será obviamente 1 (um dependente só pode estar relacionado a um empregado).

Para representar agora as

_ cardinalidades mínima e máxima, utiliza-mos o par: min e max. Assim, do lado do empregado, a repre sen tação

47

das cardinalidades será (1, 1) e do lado do dependente será (0, N), conforme a Figura 2.12.

Da entidade que participa num relacionamento em que não seja obri-gatória a presença, diz-se que é uma entidade fraca. Assim, elas podem ser divididas em fortes e fracas. A entidade fraca também é represen-tada na literatura como sendo um retângulo com linha dupla incluindo a ligação com o relacionamento.

Figura 2.12 – Relacionamento empregado-dependente representando obrigatoriedade

EMPREGADO FILIAÇÃO DEPENDENTE (1,1) (0,N)

EMPREGADO FILIAÇÃO DEPENDENTE

e1 e1,d1 d1 e2 e1,d2 d2 e3 e2,d3 d3 e4 e3,d4 d4 e5 e3,d5 d5

Na figura acima, você vê a representação do diagrama de ocorrências. Como nele, a entidade “dependente” possui cardinalidade mínima 0 (não há obrigatoriedade), existem instâncias de “empregado” que não

estão associados a qualquer instância de “dependente” (e4 e e5). Note também que todas as instâncias de “dependente” estão associadas a suas respectivas instâncias de “empregado”.

[

atributos de relacionamento

]

Assim como uma entidade pode possuir atributos, um relacionamento também pode ter atributos que não ficariam bem localizados nas suas entidades associadas.

No relacionamento “funcionário-projeto” (Figura 2.13), usaremos um

atributo, a ser colocado, chamado tempo para guardar as horas traba-lhadas pelo funcionário no projeto específico. Se o atributo “tempo” ficar ligado à entidade “funcionário”, a informação referenciada nesse atributo será relativa ao funcionário, não importando o projeto. Por outro lado, se o atributo “tempo” ficar ligado à entidade “projeto”, ele é compreendido mais como o tempo trabalhado no respectivo projeto, não importando qual funcionário trabalhou. Portanto, se for ligado a qualquer uma das entidades, o atributo não atinge o objetivo, sendo, em nosso exemplo (Figura 2.13) necessário colocar o atributo “tempo” ligado ao relacionamento “alocação” para dessa forma significar as horas trabalhadas pelo funcionário no projeto específico.

Figura 2.13 – Exemplo de atributo de relacionamento

FUNCIONÁRIO ALOCAÇÃO PROJETO N N

49

[

generalização/especialização

]

Também chamada de subtipo, a generelização/especialização per-mite que uma entidade se diferencie em vários tipos. Por exemplo, se alguns empregados são programadores, e todos os programadores são empregados, então, podemos dizer que “programador” é um subtipo do supertipo “empregado”. nessa situação, se analistas também exis-tem como empregados, então “analista” também será um subtipo do supertipo “empregado” (Figura 2.14).

Podemos, portanto, discutir a existência de herança entre entidades, bem como a de uma hierarquia de tipos, porquanto, com a

generaliza-ção/especialização, a entidade caracterizada como supertipo assume as propriedades do subtipo em determinadas ocorrências. A represen-tação de generalização/especialização num diagrama E-R se faz com um triângulo invertido. A aqui utilizada (representação) se deve a Korth e Silberschatz7_{, mas outras formas também são encontradas em Heuser}8_.

Figura 2.14 – Exemplo de generalização/especialização

PROGRAMADOR ANALISTA EMPREGADO

A herança entre as entidades pressupõe que uma entidade subtipo ou

filha pode herdar as propriedades da que é supertipo ou pai. Como propriedades são compreendidos os atributos e relacionamentos da entidade-pai.

No diagrama da Figura 2.15, vemos um exemplo onde (no contexto de um sistema de livraria) a entidade “cliente” está associada à entidade “mídia” através do relacionamento “venda”. Veja que pelo diagrama, “mídia” pode assumir uma ocorrência da entidade-filha “livro” ou uma ocorrência da outra entidade-filha “revista”. Veja que “mídia” possui o atributo identificador “ID” e “nome”, que identifica, por sua vez, uma ins-tância de “mídia”. Atributo que irá servir tanto para “livro” quanto para “revista”. Agora, quando “mídia” assume a ocorrência da entidade-filha “livro”, esta irá herdar os atributos que pertencem à mídia (ID e nome) mais os seus atributos específicos (ou seja, ISBN e ano). Quando “mídia” assume a ocorrência da entidade-filha “revista”, esta irá herdar os atribu-tos de “mídia” (ID e nome) mais os seus atribuatribu-tos específicos (que agora são ISSN e periodicidade). Além disso, as entidades-filha irão herdar tam-bém o relacionamento “vendas” que existe com a entidade “cliente”.

Figura 2.15 – Exemplo de generalização/especialização com atributos e relacionamento

Num diagrama E-R, contemplando generalização/especialização, pode-mos também fazer com que existam vários níveis, uma vez que um subti po pode ser ao mesmo tempo um supertipo e assim há um novo

CLIENTE VENDA LIVRO REVISTA NOME ID QUANTIDADE PREÇO NOME ID PERIODICIDADE ISSN ANO ISBN (1,N) (1,N) MÍDIA

51

nível de hierarquia de tipos. O exemplo da Figura 2.16 pode ser esten-dido de forma a ilustrar a inclusão de mais um nível. Veja que agora mídia pode se projetar na entidade-filha “filme”. Esta, por sua vez, é a entidade-pai de outras duas entidades: “VHS” e “DVD”. Note que o atributo duração está colocado na entidade-pai “filme”, pois tanto “VHS” quanto “DVD” possuem certa duração.

Figura 2.16 – Exemplo de generalizacão/especialização com mais níveis

[

um diagrama

E

-

R

mais complexo

]

Na Figura 2.17, encontra-se um diagrama E-R com um número maior de entidades e relacionamentos descrevendo uma parte de um sistema comercial.

CLIENTE VENDA

LIVRO FILME REVISTA

MÍDIA NOME ID QUANTIDADE PREÇO NOME ID PERIODICIDADE ISSN ANO ISBN (1,N) (1,N) VHS DVD DURAÇÃO

Nele observamos duas entidades – “clientes” e “pedido” – relaciona-das entre si. O relacionamento não apresenta um nome, mas poderia ter qualquer descrição que fosse considerada a mais apropriada ao con-texto. A descrição, ali encontrada, significa que os clientes fazem pedi-dos. A cardinalidade máxima N ao lado da entidade “pedido” indica que um cliente pode fazer mais de um pedido, porém um pedido pode ser associado somente a um cliente, como indica a cardinalidade máxima 1 que está ao lado da entidade “cliente”. Na questão da cardinalidade mínima ou obrigatoriedade, vemos que um pedido sempre estará asso-ciado a pelo menos um cliente, porém a cardinalidade mínima 0 ao lado de “pedido” indica que um cliente pode não estar associado a um pedido. Pode-se notar também que a entidade “cliente” possui um atributo chave ou identificador “código”. Assim, este atributo indicará individualmente cada instância ou ocorrência de um cliente simbolizado pela entidade “cliente”. Quanto à entidade “pedido”, também possui um código iden-tificando cada pedido individualmente. Porém, o relacionamento indica que para o pedido estar associado ao cliente, a instância de “pedido” precisa estar associada a uma instância de “cliente”, e assim a ligação do relacionamento identificador estar enfatizada do lado de pedido*. Deve-se imaginar a entidade “pedido” como sendo uma “aglutinadora” de itens. Um cliente pode solicitar mais de um item constando em um pedido. Assim, “pedido” está associada à entidade “itens” por um rela-cionamento não nominado. A obrigatoriedade indicada pelas cardina-lidades mínimas mostra que deve existir pelo menos um item para um pedido (logicamente, se existe um pedido deve existir pelo menos um item associado a este pedido). A cardinalidade máxima indica que um

* No modelo lógico relacional isso é entendido como sendo o código do cliente fazendo parte da relação “pedido” como uma chave externa ou estrangeira, como será visto mais adiante.

53

pedido pode estar associado a vários itens, porém um item deve estar associado a um único pedido.

Da mesma forma que o relacionamento anterior, deve-se notar que existe um atributo chave ou identificador para o item. Um item poderá ser numerado para cada pedido começando, por exemplo, do item número 1 até o item máximo. Como poderemos ter vários itens de número 1, precisamos fazer o relacionamento identificador do lado da entidade “item”, de forma que o atributo chave esteja associado ao atri-buto chave da entidade “pedido”. Agora será permitido referenciar ade-quadamente o pedido 1000 com o seu item 1 e o pedido 1001 também com o seu item 1 respectivo.

O relacionamento “item-produto” associa as entidades “itens” e “esto-que”. A cardinalidade indica que um item pode ter mais de um produto em estoque (ou seja, um item de pedido poderá possuir mais de um pro-duto. Isso pode acontecer em termos reais como numa promoção, por exemplo, em que dois ou mais produtos são oferecidos com certo des-conto). A cardinalidade mínima 0 do lado da entidade “estoque” indica que uma instância de “estoque” não é obrigada a participar de uma ins-tância de “item”. Notamos também que o relacionamento “item-pro-duto” possui dois atributos: “preço” e “desconto”. Esses atributos não poderiam estar ligados à entidade “estoque”, pois iriam indicar que o preço e desconto seriam sempre os mesmos não importasse o item. Por outro lado, caso estivessem ligada à entidade “item”, se houvesse mais de uma instância de produto para um item, o preço e o desconto teriam que ser entendidos como os mesmos para os produtos associados a este item. Assim, o relacionamento fica com os dois atributos*.

* Num modelo relacional, esse relacionamento se transformará em uma tabela com seus atributos próprios e os códigos (que são identificadores) respectivos de cada entidade associada.

Figura 2.17 – Exemplo de diagrama E-R sobre uma parte de um sistema comercial CLIENTE PEDIDO NOME CODIGO (1,1) (0,N) TELEFONE LIMITE_COMPRA VALOR (1,1) DATA CODIGO ESTOQUE ITEM_ PRODUTO ITENS (0,N) (1,1) (1,N) CODIGO SUBTOTAL QTD DESCONTO PREÇO PRAZOENT (1,N) CUSTO PROD_ FORNECEDORES FORNECEDOR (1,N) CODIGO NOME TELEFONE UF ULTENT PTOPED ESTMIN CODIGO DESCRIÇAO QTD

O último relacionamento “prod_fornecedor” associa as entidades “estoque” e “fornecedor”. Este relacionamento significa quais produ-tos no estoque são fornecidos por quais fornecedores. Um produto em estoque pode ser fornecido por vários fornecedores. Um fornecedor pode fornecer mais de um produto (veja a cardinalidade máxima N dos dois lados). O relacionamento é obrigatório também, ou seja, um item sempre deve estar associado a pelo menos um fornecedor. E um

forne-55

[

entidade associativa

]

Em certos momentos, num processo de modelagem de um diagrama E-R, veremos que será necessário associar uma entidade a um relacio-namento. Porém, não se pode pela regra de associação de diagramas E-R associar um relacionamento a outro. Por exemplo, no diagrama E-R explicado anteriormente, caso queiramos associar uma entidade denominada “ordem de compra” para que possamos controlar os pro-dutos que são solicitados aos fornecedores, a qual entidade associar? Se associarmos diretamente à entidade “estoque”, não teremos como ligar a qual fornecedor será feita a ordem de compra. Caso associemos com a entidade “fornecedor”, não teremos a informação de produto para solicitar. A solução seria relacionar diretamente com o próprio relacionamento “prod_fornecedor”, que vem a ser onde encontramos as duas informações juntas. Porém, não podemos ligar dois relaciona-mentos. Assim, transformamos o relacionamento “prod_fornecedor” numa entidade associativa (Figura 2.18), e agora poderemos estabele-cer um relacionamento entre a entidade associativa “prod_fornecedor” e a entidade “ordem de compra”. O símbolo para uma entidade asso-ciativa é um retângulo sobrescrevendo um losango.

Podemos pensar num modelo equivalente, caso não queiramos traba-lhar com a entidade associativa*. Assim, para o novo modelo, trans-forma-se a entidade associativa “prod_fornecedor” em uma entidade, e associa-se esta a cada entidade do diagrama E-R com seus respectivos relacionamentos exigidos pelo padrão de diagramação.

* Na conversão de um diagrama E-R para um modelo relacional, o processo é mais simples sem o uso de entidade associativa.

Figura 2.18 – Exemplo de entidade associativa FORNECEDOR (1,N) CODIGO NOME TELEFONE UF ULTENT ESTOQUE PRAZOENT (1,N) CUSTO PTOPED ESTMIN CODIGO DESCRIÇAO QTD ORDEM DE COMPRA PROD_ FORNECEDOR

Note que no diagrama E-R, da Figura 2.19, foi substituída a entidade associativa pela entidade “prod_fornecedor”, tendo relacionamentos com as outras entidades: “estoque” e “fornecedor”. Com a entidade “ordem de compra”, existe um relacionamento que permite identificar a ordem de compra com o código respectivo, e esta instância pode

aglu-tinar (como acontece na entidade “pedido” descrita anteriormente) vários pares produto-fornecedor. E a quantidade a ser requisitada é colocada no relacionamento, pois, a cada nova ordem de compra, quantidades diferentes poderão ser solicitadas. Não faria sentido se fosse colocado o atributo da quantidade na entidade “ordem de com-pra”, nem mesmo na entidade “prod_fornecedor”.

57

Figura 2.19 – Uma alternativa para o diagrama anterior sem entidade associativa

FORNECEDOR CODIGO NOME TELEFONE UF ULTENT ESTOQUE PRAZOENT (1,1) CUSTO PTOPED ESTMIN CODIGO DESCRIÇAO QTD ORDEM DE COMPRA PROD_ FORNECEDOR (1,N) (1,1) (1,N) (1,N) (1,1) QTD CODIGO

[

resumo

]

O modelo entidade-relacionamento, difundido por Chen, permite agre-gar à representação dos dados aspectos semânticos, apresentando um bom ponto de partida para a compreensão daquilo que normalmente não transparece num banco de dados relacional. Basicamente o modelo propõe a representação da entidade, que pode ser um elemento con-creto ou abstrato, referente a algo pessoal, lugar, objeto, evento ou conceito; do atributo, que são as características da entidade, pode ser simples ou derivado; e do relacionamento, que associa uma ou mais entidades. O tipo de relacionamento, de acordo com o número de enti-dades que participam da relação, pode ser unário, binário ou ternário. A obrigatoriedade refere-se a situações em que há necessidade da pre-sença de uma entidade, ou não, contendo o conceito de cardinalidade (o número de elementos associados à entidade). Uma entidade que par-ticipa de um relacionamento é dita fraca no caso de não ser obrigató-ria a sua presença. Um relacionamento também pode possuir atributos, assim como uma entidade, na qual a presença de tais atributos faça mais sentido ao modelo do que se estivessem ligados às entidades participan-tes. A diferenciação de uma entidade em subtipos e supertipos também é possível, sendo tal representação hierárquica denominada de

genera-lização-especialização. A entidade associativa permite a representação de uma entidade que evita a conexão entre dois relacionamentos, o que não é permitido pelo modelo E-R.

59

[

exercícios

]

1. Porque a abordagem modelo entidade-relaciona-mento é útil para a modelagem de bancos de dados? 2. Quais são os elementos que podem constar em um diagrama E-R?

3. O que vem a ser uma instância?

4. Dê um exemplo de relacionamento para cada tipo de cardinalidade: 1:1, 1:N e N:N.

5. Elabore os seguintes diagramas E-R de acordo com as entidades e atributos a seguir enumerados:

a) Aluno (matricula, nome), curso (código, nome). Um aluno pode fazer mais de um curso.

6. Na terminologia da abordagem E-R, o que são

papéis?

7. Num relacionamento unário ou auto-relaciona-mento, uma entidade se relaciona com ela mesma. Explique.

8. Monte o auto-relacionamento para o exemplo de um plano de contas, onde temos contas e subcontas associadas entre si. Expresse os papéis e monte um diagrama de ocorrências.

9. De acordo com o exemplo de relacionamento ter-nário da Figura 2.9, como ficaria o modelo para o caso de um funcionário poder atuar em mais de uma área? Exemplifique com o diagrama de ocorrências.

10. De acordo com o exemplo de relacionamento ternário da Figura 2.9, como ficaria o modelo para o caso de mais de um funcionário poder atuar em mais de um projeto e área? Exemplifique com o dia-grama de ocorrências.

11. Dê um exemplo de relacionamento quaternário. Expresse um diagrama de ocorrências para exempli-ficar as instâncias.

12. Fale sobre obrigatoriedade.

13. Utilize o exemplo de relacionamento da Figura 2.6 e especifique a cardinalidade mínima e máxima para a situação em que o funcionário pode estar ou não em um projeto, e um projeto pode possuir ou não funcionários.

14. Com base nos esquemas abaixo, elabore um dia-grama E-R para um sistema de biblioteca:

a) Mídia(cod midia,titulo) Usuário(cod usuario, nome) Autor(cod autor,nome)

b) Editora(cod editora,nome,telefone)

Algumas considerações para a construção do modelo:

_ cada esquema denota uma entidade que fará parte do diagrama;

_ entre parênteses constam os atributos que fazem parte de cada entidade;

61

_ por mídia deve ser entendido tudo que existe na biblioteca (livros, fitas, CDs etc.);

_ um usuário pode tomar emprestadas várias mídias existentes no acervo de mídias;

_ para cada mídia que seja emprestada ao usu-ário, deve ser registrada uma data de emprés-timo, a de previsão da entrega e a da entrega; _ devemos considerar também a existência de um relacionamento para as entidades Mídia e Usuário;

_ uma mídia pode ter vários autores, porém uma única editora.

63

álgebra

relacional_