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
Responder
rodrigo vasconcelos
Rank: Estagiário Júnior
Rank: Estagiário Júnior
Mensagens: 2
Registrado em: Qua, 12 Abr 2006 10:59 am
Localização: rio verde/go
DEVELOPER

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 ..
Avatar do usuário
stcoutinho
Moderador
Moderador
Mensagens: 850
Registrado em: Qua, 11 Mai 2011 5:15 pm
Localização: são Paulo - SP

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_preço
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
Responder
  • Informação
  • Quem está online

    Usuários navegando neste fórum: Nenhum usuário registrado e 18 visitantes