Converter um diagrama ER para código SQL [fechado]
Este é o diagrama ER, para o qual as tabelas têm de ser feitas no código SQL implementando todas as restrições. Eu fiz tabelas e tentei implementar toda a relação através de chaves estrangeiras, eu jus queria confirmar, se estas tabelas estão corretas ou não.
1) Tabela do Departamento:
create table department(dpet_id number primary key, dept_name varchar2(15)
not null);
2) Tabela de Ramos:
create table branch(branch_id varchar2(5) primary number, electives varchar2(10),
dept_id number references department(dept_id));
3) Tabela dos cursos:
create table course(course_id number primary key, course_name varchar2(10)
not null,branch_id varchar2(5) references branch(branch_id));
4) Tabela de estudantes:
create table student(stud_id number primary key, stud_name varchar2(30) not null,
branch_id varchar2(5) references branch(branch_id);
5) Tabela do requerente:
create table applicant(app_id number primary key, stud_id number constraint fk
references student(stud_id) constraint stu_unq unique);
6) Applicant_branch quadro:
create table applicant_branch(app_id number references applicant(app_id),
branch_id varchar2(5) references branch(branch_id));
estas tabelas estão em conformidade com o diagrama das urgências ?
2 answers
O seu diagrama de ER mostra um modelo conceptual do assunto. Isto é uma coisa boa.
Para referência futura, existem dois passos intermédios entre um modelo conceptual e um script SQL create. Eles são design lógico e design físico.
O design lógico muda o modelo conceitual para um modelo lógico, e adiciona algumas características. O modelo lógico é relacional (na maioria dos casos). Uma característica adicional é chaves estrangeiras. Aqui é onde você normaliza, se você escolher normalizar.
O design físico muda o modelo lógico para um modelo físico, e adiciona algumas características. O modelo físico é expresso em termos SQL; como tabelas, linhas e Colunas. É específico do DBMS. Ele adiciona recursos como índices e muitas características específicas DBMS, como mapeamento de tablespace e outros. Nesta fase, você considera o volume de dados, o tráfego previsto, e a produção considerar ações.
Finalmente, convertes o modelo físico numa criação roteiro.Para problemas muito pequenos, estes estágios podem ser colapsados em um estágio, como você parece ter feito. Para projetos muito grandes, é melhor mantê-los separados.