Le 27 février 2015 17:13:42 GMT-03:00, "Flávio Silveira" <[email protected]> a écrit : > > Certo, é que eu resolvi dar muita atenção ao modelo relacional e > comprrende-lo bem, antes de me aventurar > pelo mundo SQL em si.
Entendo, mas é o contrário. O modelo relacional nada tem a ver com diagramas. Embora o SQL também não seja relacional, é muito mais próximo do modelo relacional que qualquer diagrama. > Tenho certeza que seria, mas eu preciso praticar e futuramente isso > será integrado num ERP > que estou desenvolvendo para a empresa. Exatamente, seria melhor você começar com um ERP já pronto, e aprender a adaptá-lo. Veja os ERPs que funcionam com PostgreSQL. Aliás, lembrei doutro: o Adempière. > É por causa desse ERP que > comecei a estudar Banco de Dados e > também a razão pela qual comecei uma faculdade de Análise e > Desenvolvimento de Sistemas. Cuidado, essas faculdades são 90% caça níqueis, e costumam ensinar dados muito erradamente. Até hoje, só vi no Brasil algumas poucas universidades públicas onde um ou outro professor ensina isso corretamente. Não que faculdade seja dispensável neste país, mas quanto a dados você aprende mais com os livros do Date. > Como sou novato e para não complicar muito a validação dos cadastros > eu pensei em usar IDs para garantir unicidade, futuramente pretendo >trocar ID por CNPJ, CPF e código do Banco respectivamente assim que eu >for evoluindo. Parece sensato, concorda? Só parece. Primeiro, que você não deve criar algo sabendo que já terá de mudar; melhor entender primeiro as razões das coisas. Invista no livro do Date, gaste algumas semanas nisso, daí continue. Queimar etapas não vai te ajudar. Segundo, ID nunca garante unicidade. O que garante unicidade são chaves naturais. CPF, CNPJ e código do banco (aquele que é 1 para o BB, por exemplo) costumam ser chaves naturais razoáveis, em muitos casos. Pense: se você tiver apenas IDs, o que te impede de inserir a mesma informação várias vezes, cada vez gerando uma nova tupla com um novo ID? > Exatamente, pode ser excesso de zelo meu, mas estou me dedicando >bastante a modelagem relacional para ter coisas com qualidade, mesmo >que >simples. Comecei lendo o livro Projeto Banco de Dados do Carlos Alberto >Heuser, depois comprei o Modelagem Lógica de Dados do Eduardo Bernardes >de Castro e para tentar intensificar um pouco meu conhecimento além da >leitura, comprei o curso Modelagem Relacional do Eduardo Morelli e >oferecido pela DevMedia. Não conheço livro bom de dados de autores brasileiros. Geralmente, até livros de professores da USP estão cheios de meias verdades que geram muita confusão. Guarde esses livros numa caixa, e os substitua pelo Date. Sério. Só para dar um exemplo, vários empregos atrás me louvaram muito um professor da USP que seria muito rigoroso e tinha um livro muito bom. Peguei a última edição e havia um erro óbvio. Aí conheci o tal professor e descobri o que aconteceu: o filho dele virou consultor Oracle. Aí ele deixou o rigor de lado. > Basicamente todos são claros nesse ponto de definir bem as entidades > e colocar atributos que só dependem da entidade, caso contrário tem de > ir para o relacionamento entre as entidades. Relacionamento não é um conceito relacional. Se os livros não explicam isso, só servem para peso de porta. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:[email protected] +55 (61) 9302 2691 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:[email protected] _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
