2016-08-25 14:41 GMT-03:00 Tiago José Adami <adam...@gmail.com>: > > Mas o uso de UK's (você se refere a UNIQUE INDEXES, certo?)
Na verdade, chaves alternativas. Uma relação tem n chaves, onde n >= 1. Assim, além da chave primária pode haver o outras chaves, onde o >= 0. É irrelevante qual das chaves se escolhe como primária, esse conceito de chave primária está obsoleto e é vazio. > não > garante a integridade lógica entre as tabelas, apenas entre os > registros de uma só tabela. Não exatamente, a função das chaves alternativas, além de documentar o modelo, tornando-o mais transparente (de fácil compreensão), é justamente possibilitar a convivência de chaves naturais e artificial; nos raros casos em que há exagero de consumo de memória por uso de chaves naturais complexas se reproduzindo em tabelas filhas muito maiores que as pais, pode-se ‘exportar’ a chave artificial, garantindo a integridade referencial, enquanto as naturais seguem garantido a unicidade. Mas há que se lembrar que cada chave artificial é um atributo e um índice a mais, custando não apenas memória mas também E/S. Creio que não é esse caso que exemplificaste abaixo, é? > Por exemplo, eu poderia ter a tabela de > reservas como antes: > > CREATE TABLE reserva ( > /* PK artificial, única */ > id_reserva SERIAL NOT NULL, > > /* FK tabela ITEM_RESERVA */ > id_item_reserva INTEGER NOT NULL, > > /* FK tabela PESSOA */ > id_pessoa INTEGER NOT NULL, > > (...) > ) > > Uma das regras do sistema é que apenas servidores do próprio campus > possam fazer reservas dos itens do seu campus. > > Nesse modelo com chaves artificiais acima, mesmo que haja um índice > único não impede de fazer uma reserva de um item do campus A para uma > pessoa do campus B. Só se você implementar um TRIGGER que valide isso > e retorne uma exceção, mas aí já começa a complicar demais o modelo. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
