Converter um diagrama ER para código SQL [fechado]

Question

Converter um diagrama ER para código SQL [fechado]

enter image description here

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 ?

1

sql foreign-keys create-table entity-relationship

Author: Rubbal Bhusri, 2013-08-07

Source

2 answers

A única coisa que posso acrescentar a isto é que não há relação entre estudante e departamento. Depende do teu cenário, queres ou não. Mas acho que devia ser. Para que você possa distinguir entre os alunos de um departamento prticular. Também estás a fazer um filme, como se o branch estivesse sob controlo. é este o caso?

1

Author: Shaikh Farooque, 2013-08-07 12:27:28

score 2 · Accepted Answer

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.