2016-03-03 15:40 GMT-03:00 Andre Cavalcante <andre.d.cavalca...@gmail.com>: > > 2016-03-02 9:52 GMT-04:00 Guimarães Faria Corcete DUTRA, Leandro > <l...@dutras.org>: >> >> 2016-03-02 9:13 GMT-03:00 Andre Cavalcante <andre.d.cavalca...@gmail.com>: >> > Aprendiz >> > ----------- >> > id serial >> > matricula varchar >> > nome varchar >> >> Cada um é uma chave? Ou a chave são os dois atributos? > > id é uma chave primária porque gerado automaticamente pelo banco - é só o id > do objeto
Certo. Só lembre que uma chave dessas não cumpre a principal função de uma chave, que é a de garantir unicidade, nem a de documentar o modelo (motivo pelo qual perguntei por chaves naturais). Falando sobre documentação, evite usar simplesmente id como nome de atributo. Se não tiver jeito de declarar uma chave natural como primária (geralmente tem), ao menos dê ao atributo um nome único e consistente em toda a base, por exemplo (no caso) id_aprendiz. > matricula é uma chave candidata (unique no banco) > nome + nomePai + nomeMae é outra chave candidata (unique no banco) > > Mas note que isso é apenas para mater o banco estável e com integridade > relacional. As verificações mesmo são feitas no modelo OO. Cuidado. Além de não funcionar na manipulação direta do banco por usuários ou outros aplicativos, pode levar a relaxar nas verificações de integridades no banco (que são muito mais que as referenciais), e sobretudo a não pensar no modelo em si. > Pensei nisso também, mas como tudo tem um id Isso normalmente é um mau sinal. > e a como parte da chave > candidata em questão é uma data, deixei assim. Qual o problema de ser data? > Aí é que está, não tem tanta regra de negócio assim associado. É > simplesmente um documento que é anexado a um item de histórico. Podem ser > quantos o operador quiser (e.g. scanner .jpg de RG, CPF ou outro doc). É só > um repositório para cada item, daí a FK com id de ItemHistorico Hm, acho que entendi. Na verdade, se o usuário pode anexar o mesmo documento várias vezes, caberia um contador, caso em que passa a haver chave candidata; ou então identificador de instância (por exemplo, ordem em que foi anexado), caso em que volta a haver chave candidata. Sempre há chave candidata, a gente é que nem sempre pensa o suficiente — ou decide deixar o modelo frágil por ser relativamente pouco importante, mas aí se paga mais tarde com inconsistências internas ou externas (do banco consigo mesmo ou com a realidade. > 2. No modelo proposto, como fazer a SQL que retorne todos o documentos > entregues por um aprendiz? Não entendi qual o problema, porque não fazer uma junção entre as relações? Você chegou a tentar e não conseguiu? Até onde chegou, e qual o resultado obtido? Talvez facilite usar o pg_autodoc, o SchemaSpy ou o SQL::Fairy para poder enxergar o modelo, pode ser que o uso de ids esteja atrapalhando o entendimento. Acontece mesmo com modelos que a gente mesmo criou. -- 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
