Classificação de modelo de dados
Esse artigo tem por objetivo demonstrar as diferenças entre os tipos de modelos de dados (Conceitual Lógico e Físico).
Modelo de Dados é um conjunto de conceitos que se usa para descrever a estrutura do Banco de Dados.
Os modelos de dados podem ser classificados em três categorias:
· Modelo de Dados Conceituais: é um modelo que descreve o banco de dados como é visto no mundo sem se preocupar com detalhes de implementação. Como exemplo: Entidade – Relacionamento. Representa fielmente o negocio em questão, demonstrando características fieis ao ambiente observado ou imaginado independente de qualquer limitação imposta por tecnologia, técnica de implementação ou dispositivo físico.
Deve ser utilizada na fase de analise, nunca na fase de projeto, em nível de conversação, representação do negocio, validação de conceitos etc. Um grande diferencial do modelo conceitual é sua estabilidade, pois permanece sem mudanças independente da escolha futura de implementação, em um SGBD relacional ou um hierárquico, por exemplo. Outro aspecto positivo do modelo conceitual é que como o mesmo não respeita regras e limitações imposta pela tecnologia, as pessoas que estarão desenvolvendo o modelo irão concentrar todo seu esforço no aspecto conceitual, obtendo, desta forma, maior detalhamento do conceito nessa fase.
· Modelo de Dados Lógicos: modelo intermediário entre o nível conceitual e o nível físico. Como exemplo: Modelo Relacional. Ao contrário dos modelos conceituais, os modelos lógicos são os modelos em que os objetos, suas características e relacionamentos têm sua representação de acordo com as regras de implementação e limitantes impostos por alguma tecnologia, modelo esse utilizado já na fase de projeto, mais independente de dispositivo físico, implementando conceitos como chave primaria, normalização, integridade referencial, chaves compostas e outros.
Segundo Martins (2007), esse modelo será criado através do modelo conceitual já construído, teoria essa que alguns autores têm uma visão diferenciada, definindo que o método para obtenção do modelo lógico é o próprio processo criativo, sem haver a necessidade de um modelo conceitual.
· Modelo de Dados Físicos: descreve o banco de dados como vai estar no nível físico de armazenamento. Elaborado a partir do Modelo lógico levando em consideração limites impostos por dispositivo físico e pelos seus requisitos não funcionais dos programas que acessam os dados, cada dispositivo físico (SGBD) diferente poderá definir um modo diferente de implementação física das características e recursos necessários para o armazenamento e manipulação das estruturas de dados.
Segundo Pressman (2006), o modelo de dados consiste em três peças de informação inter-relacionadas: o objeto de dados, os atributos que descrevem o objeto de dados e as relações que conectam os objetos de dados uns aos outros.
CREATE TABLE curso (
codigo_curso NUMBER,
nome VARCHAR2(30) NOT NULL,
CONSTRAINT curso_pk PRIMARY KEY (codigo_curso)
);
CREATE TABLE projeto (
codigo_projeto NUMBER,
titulo VARCHAR2(30) NOT NULL,
conceito VARCHAR2(7),
hp VARCHAR2(50),
CONSTRAINT projeto_pk PRIMARY KEY (codigo_projeto),
CONSTRAINT projeto_conceito_ck CHECK (conceito IN ('BOM', 'RUIM', 'REGULAR'))
);
CREATE TABLE pessoa (
matricula_pessoa NUMBER,
nome VARCHAR2(50) NOT NULL,
sexo CHAR(1) NOT NULL,
CONSTRAINT pessoa_pk PRIMARY KEY (matricula_pessoa)
);
CREATE TABLE professor (
matricula_professor NUMBER,
data_admissao DATE NOT NULL,
matricula_lider NUMBER,
CONSTRAINT professor_pk PRIMARY KEY (matricula_professor),
CONSTRAINT professor_matricula_prof_fk FOREIGN KEY (matricula_professor) REFERENCES pessoa (matricula_pessoa),
CONSTRAINT professor_matricula_lider_fk FOREIGN KEY (matricula_lider) REFERENCES professor (matricula_professor)
);
CREATE TABLE disciplina (
codigo_disciplina NUMBER,
ementa VARCHAR2(50) NOT NULL,
conteudo_programatico VARCHAR2(100) NOT NULL,
matricula_professor NUMBER NOT NULL,
CONSTRAINT disciplina_pk PRIMARY KEY (codigo_disciplina),
CONSTRAINT disciplina_matricula_prof_fk FOREIGN KEY (matricula_professor) REFERENCES professor (matricula_professor)
);
--fazer um check para poder ter apenas um professor
CREATE TABLE turma (
codigo_disciplina NUMBER,
codigo_curso NUMBER,
ano_semestre VARCHAR2(6),
CONSTRAINT turma_pk PRIMARY KEY (codigo_disciplina,codigo_curso,ano_semestre),
CONSTRAINT turma_codigo_disciplina_fk FOREIGN KEY (codigo_disciplina) REFERENCES disciplina (codigo_disciplina),
CONSTRAINT turma_codigo_curso_fk FOREIGN KEY (codigo_curso) REFERENCES curso (codigo_curso),
CONSTRAINT turma_ano_semestre_ck CHECK (ano_semestre LIKE '____._')
);
CREATE TABLE ministra (
codigo_disciplina NUMBER,
codigo_curso NUMBER,
ano_semestre VARCHAR2(6),
matricula_professor NUMBER,
CONSTRAINT ministra_pk PRIMARY KEY (codigo_disciplina,codigo_curso,ano_semestre,matricula_professor),
CONSTRAINT ministra_turma_fk FOREIGN KEY (codigo_disciplina,codigo_curso,ano_semestre) REFERENCES turma (codigo_disciplina,codigo_curso,ano_semestre),
CONSTRAINT ministra_matricula_prof_fk FOREIGN KEY (matricula_professor) REFERENCES professor (matricula_professor)
);
CREATE TABLE aluno (
matricula_aluno NUMBER,
nota_vestibular DECIMAL(5,3) NOT NULL,
codigo_curso NUMBER NOT NULL,
CONSTRAINT aluno_pk PRIMARY KEY (matricula_aluno),
CONSTRAINT aluno_matricula_aluno_fk FOREIGN KEY (matricula_aluno) REFERENCES pessoa (matricula_pessoa),
CONSTRAINT aluno_codigo_curso_fk FOREIGN KEY (codigo_curso) REFERENCES curso (codigo_curso)
);
CREATE TABLE aluno_turma (
codigo_disciplina NUMBER,
codigo_curso NUMBER,
ano_semestre VARCHAR2(6),
matricula_aluno NUMBER,
codigo_projeto NUMBER,
CONSTRAINT aluno_turma_pk PRIMARY KEY (codigo_disciplina,codigo_curso,ano_semestre,matricula_aluno),
CONSTRAINT aluno_turma_turma_fk FOREIGN KEY (codigo_disciplina,codigo_curso,ano_semestre) REFERENCES turma (codigo_disciplina,codigo_curso,ano_semestre),
CONSTRAINT aluno_turma_matricula_aluno_fk FOREIGN KEY (matricula_aluno) REFERENCES aluno (matricula_aluno),
CONSTRAINT aluno_turma_codigo_projeto_fk FOREIGN KEY (codigo_projeto) REFERENCES projeto (codigo_projeto)
);
CREATE TABLE prova (
codigo_disciplina NUMBER,
codigo_curso NUMBER,
ano_semestre VARCHAR2(6),
matricula_aluno NUMBER,
descricao VARCHAR2(10),
nota DECIMAL(3,1) NOT NULL,
CONSTRAINT prova_pk PRIMARY KEY (codigo_disciplina,codigo_curso,ano_semestre,matricula_aluno,descricao),
CONSTRAINT prova_aluno_turma_fk FOREIGN KEY (codigo_disciplina,codigo_curso,ano_semestre,matricula_aluno) REFERENCES aluno_turma (codigo_disciplina,codigo_curso,ano_semestre,matricula_aluno)
);
CREATE TABLE monitoria (
codigo_disciplina NUMBER,
codigo_curso NUMBER,
ano_semestre VARCHAR2(6),
matricula_aluno NUMBER,
matricula_professor NUMBER NOT NULL,
CONSTRAINT monitoria_pk PRIMARY KEY (codigo_disciplina,codigo_curso,ano_semestre,matricula_aluno),
CONSTRAINT monitoria_turma_fk FOREIGN KEY (codigo_disciplina,codigo_curso,ano_semestre) REFERENCES turma (codigo_disciplina,codigo_curso,ano_semestre),
CONSTRAINT monitoria_matricula_aluno_fk FOREIGN KEY (matricula_aluno) REFERENCES aluno (matricula_aluno),
CONSTRAINT monitoria_matricula_prof_fk FOREIGN KEY (matricula_professor) REFERENCES professor (matricula_professor)
);
Referência Bibliográficas
Pressman, Roger S. Engenharia de Software, 2006
Martins, José Carlos Cordeiro. Gerenciando Projetos de Desenvolvimento de Software – 2ª e 4ª edições, 2007.
Bom dia!
Esta publicação é muito interessante, sou aluna o curso de Licenciatura em informática e estou cursando a disciplina de banco de dados, gostaria de saber se você poderia me ajudar com um trabalho?
Postar um comentário