NOVO EM ORACLE

Dúvidas, dicas e truques de PL/SQL. Aqui também vão assuntos relacionados a pacotes, triggers, funções, Java-Stored Procedures, etc
  

Mensagemem Qua, 12 Abr 2006 11:16 am

Gente,
Eu sou o "mascotinho" de vocês...
Mas também pretendo ser um consultor futuramente.
Estou embarcando com tudo.
A princípio gostaria que vocês me explicassem de forma mais simples sobre:
- chave primária e chave estrangeira
- empacotamento
- interface
E quero muito saber sobre domínio no contexto de banco de dados..
Amo vocês em oracle.
Aguardo.
Rodrigo
Editado pela última vez por stcoutinho em Sáb, 11 Jan 2014 1:56 pm, em um total de 1 vez.
Razão: Editado inicialmente em letras maiusculas .. formatei o texto (minisculas) para faciliar leitura ..
rodrigo vasconcelos
Localização: rio verde/go

DEVELOPER

Mensagemem Sáb, 11 Jan 2014 2:23 pm

Rodrigo,

Estou respondendo este tópico antigo em aberto, no caso de algum forista do GLUFKE se deparar com alguma dúvida parecida.

Não entendi exatamente o que você quer dizer com "interface" e "domínio", mas sobre constraints (restrições) de PK (primary key - chave primária) e FK (chave estrangeira), posso contribuir com algumas informações.

Nos bancos de dados relacionais em geral (pode ser MYSQL, ORACLE, DB2, SQLSERVER, SYBASE, etc), existem objetos de banco de dados chamados CONSTRAINTS (restrições), que tem o objetivo de garantir a integridade das informações armazenadas em banco.

Vamos imaginar a situação de uma NOTA FISCAL DE SUPERMERCADO. Você nota, ao visualizar a mesma, que ela é composta de um cabeçalho (onde são registrados os dados da loja e do consumidor) e itens (onde são relacionados os produtos adquiridos).

Simplificando BASTANTE os conceitos de modelagem de dados, você poderia criar "duas tabelas" compostas das seguintes colunas:

TB_NOTA_FISCAL
------------------------
NU_NOTA FISCAL [PK]
NU_CPF_CONSUMIDOR

TB_NOTA_FISCAL_ITEM
---------------------------
NU_NOTA FISCAL_ITEM [PK]
NU_NOTA FISCAL [PK] / [FK]
NO_PRODUTO
NU_QTD
VL_PRECO


Por motivos de tributação, a loja só pode emitir um único "numero de cupom fiscal". Neste caso, para garantir que a tabela TB_NOTA_FISCAL armazene somente um registro com este "numero de cupom fiscal", deve-se criar uma PK nesta tabela composta da coluna NU_NOTA_FISCAL".

Como eu estou armazenando os dados de uma nota fiscal em duas tabelas distintas, eu preciso de algo "que amarre" estas informações entre as duas tabelas, de forma que os dados de uma nota não se misturem com os itens de outra nota. Preciso também evitar que sejam criadas notas fiscais órfãs, ou seja, jamais poderei ter os ITENS de NOTA FISCAL sem o seu CABECALHO.

Neste caso, eu acabo criando uma FK na tabela TB_NOTA_FISCAL_ITEM, composta da coluna NU_NOTA_FISCAL, que aponta para a PK da tabela TB_NOTA_FISCAL.

Quando crio este relacionamento entre as tabelas, onde TB_NOTA_FISCAL é pai e TB_NOTA_FISCAL_ITEM é filha, eu estou garantindo a integridade entre as duas tabelas. Também optei por criar uma "PK composta" em TB_NOTA_FISCAL_ITEM.

A explicação que lhe passei é bem simplificada e tenho certeza que outros foristas do GLUFKE explicariam de forma mais didática/correta que a minha tentativa de agora.

Talvez o mais importante a se abstrair desta informação é que um banco de dados não é simplesmente um "depósito de dados', cuja integridade é unicamente garantida pela aplicação. Se no futuro trabalhar com banco de dados, tente aproveitar ao máximo estes recursos de integridade que o banco oferece, pois mais "free" ou "simples" que ele seja.

A ENORME vantagem que você tem ao inserir integridade no banco de dados é que estas regras não se perdem e validam em tempo real a informação que você está tentando armazenar. Quando você coloca esta validação somente nos ombros da aplicação, existe uma série de fatores que podem conspirar para comprometer a integridade de seu banco de dados. Exemplos: aplicação que sofre manutenções incorretas e que deixam de validar temporariamente os dados a serem inseridos, pessoas inserindo manualmente dados na base que não respeitam as regras de negócio, etc.

Uma visão geral sobre conceitos de banco de dados pode ser encontrada neste link da WIKIPEDIA: http://pt.wikipedia.org/wiki/Banco_de_dados

Abraços e bons estudos,

Sergio Coutinho
stcoutinho
Localização: Sao Paulo - SP



Voltar para PL/SQL

Quem está online

Usuários navegando neste fórum: Google [Bot] e 5 visitantes