Sistema Biblioteca- Modelo entidade - relacionamento

Começar do banco de dados é começar procedural. Se você vai fazer em java, porque não começar com os objetos?

Fiz no jude. Agora falta as regras de negocio.

Em primeiro lugar, você precisa definir qual a modelagem que irá seguir.
Se começar pelo DFD ou DER, implicitamente escolhe procedural, estruturado.
Se quer fazer com java, sugiro começar levantando os requisitos, criando os use cases definitions e, então, o diagrama de classes.
Afinal, o DER nem sempre reflete o diagrama de classes.

Hmm…e onde você acha que as regras de negócio devem estar?

Você criou os objetos…mas pensando nas tabelas. Nota-se isso por vários dos métodos que você criou. Se tivesse pensado nos comportamentos primeiro (ou, se preferir, regras de negócio) saberia que elas deveriam estar nesses objetos.

(procurando links para os posts do site fragmental do pcalcado, em português e não encontrando nada além de páginas da web perdidas ao vento…) :roll:

Bom, procure na internet sobre modelos de domínio no google. Vai ajudar.

Preocupar-se com o banco de dados é algo bacana, demonstra preocupação com a integridade do mesmo.
Porém, esse cuidado é algo que deve existir quando o banco de dados for o ponto do projeto, o que, neste caso, não é.
A não ser que tudo seja feito através de stored procedures, na chamada POBD - programação orientada a banco de dados.
Explico, você cria todas as lógicas dentro do banco de dados, utilizando cursores, views, functions e stored procedures. Aí, só cria uma interface gráfica do usuário (GUI) que irá interagir com as procedures.

Não é de todo errado, apenas, uma forma mais complicada de desenvolver.

há alguma forma de simplificar esse projeto. eu tow achando complicado ter que inserir dados em diferentes tabelas. Por exemplo para inserir um livro, eu tenho q dar um insert nas tabelas titulo_livro, autor, editora, estoque(esqueci de colocar no modelo fisico). Por que não só simplismente criar uma tabela livro e fazer tudo isso de uma vez?

Don´t be lazy, boy!!!

Camarada, deixa a preguiça de lado e faz direito.
Já começou errado, pelo DER, agora segura o tranco.

pronto já corrigi o DER, dê uma olhada.

Detalhes do DER:
1 - Um funcionário jamais será um usuário?
2 - Título pertence a livro, é uma parte de livro, por que está numa tabela separada?
3 - Um autor pode ter vários livros, mas um livro sempre terá apenas um autor?
4 - Se o relacionamento está correto, entre livro e autor, por que é que o autor recebe a FK de livro? Cada livro possui vários autores???
5 - Cargo e funcionário possuem uma relação 1 : 1? Não existem 2 funcionários com o mesmo cargo? Seria 1 : N (um cargo possui vários funcionários e um funcionário exerce 1 cargo por vez).
6 - Por que na tabela de relacionamento entre usuario e livro as colunas Usuario_cod_Usuario e Livro_cod_livro estão duplicados (respectivamente, cod_usuario e cod_livro)?

Detalhes do “Diagrama de Classes”:
1 - Administrador não é um funcionário?

Detalhes do DER:
1 - Um funcionário jamais será um usuário?
R: Sim. Um funcionário pode sim ser um usuário.

2 - Título pertence a livro, é uma parte de livro, por que está numa tabela separada?
R: Também achei estranha essa parte, mas o professor disse que era assim(Estudo no IFBA, ficou tres meses de greve ).

3 - Um autor pode ter vários livros, mas um livro sempre terá apenas um autor?
R: Um livro nem sempre tem apenas um autor.

4 - Se o relacionamento está correto, entre livro e autor, por que é que o autor recebe a FK de livro?
R: livro deveria receber a FK cod_autor.
Cada livro possui vários autores???
R: Nem sempre.

5 - Cargo e funcionário possuem uma relação 1 : 1? Não existem 2 funcionários com o mesmo cargo? Seria 1 : N (um cargo possui vários funcionários e um funcionário exerce 1 cargo por vez).

6 - Por que na tabela de relacionamento entre usuario e livro as colunas Usuario_cod_Usuario e Livro_cod_livro estão duplicados (respectivamente, cod_usuario e cod_livro)?
R: Eu fiz no DBdesigner. E não entendi porque o relacionamento ficou assim, no Diagrama que fiz no Microsoft SQL 2005 ficou certo =[

Detalhes do “Diagrama de Classes”:
1 - Administrador não é um funcionário?
R: Eu tava pensando em remover administrador (não tornar o programa mais complicado)

Segue abaixo o DER feito no Microsoft SQL

Ná tabela “Livro”, você poderia adicionar uma coluna relacionada a “Categoria” (Ficção, romance e etc…) e criar mais uma tabela chamada “Categoria” ou algo assim, com relacionamento N x N, pois um livro pode ter mais de uma categoria e uma categoria com certeza terá mais de um livro associado a ela. Fazendo isso você normalizará sua estrutura de banco de dados.

Ainda na tabela “Livro”, você poderia usar como chave-primária o ISBN, que é um número único de cada livro, apenas para normalizar ainda mais a estrutura.

Na minha opinião, a tabela “Titulo_livro” não é necessária. ela poderia ser transformada em um campo na tabela “Livro”, afinal, um livro só pode ter um título, correto? Não tenho certeza, mas acho que sim…

Acho que é isso.