Diseño fisico de la base de datos

Aqui esta el diseño fisico de la base de datos: Aqui os dejo una pequeña parte del script en la que se muestran los tipos de datos de algunas tablas asi como sus restricciones y relaciones.

create if not exists table tblprofesores
(
id_profesor int primary key auto_increment,
nombre varchar(30) not null,
apellido varchar(30) not null,
id_pais int not null,
id_ciudad int not null,
direccion varchar(100) not null,
constraint fk_profesor_pais foreign key(id_pais) references tblpaises(id_pais),
constraint fk_profesor_ciudad foreign(id_ciudad) references tblciudades(id_ciudades)
);

create table if not exists tblprofesor-titulouniversitario
(
id_titulo int not null,
id_profesor int not null,
id_institucion int not null,
ano_obtencion date not null
constraint chk_ano_obtencion check(ano_obtencion between(1900,2100)),
constraint fk_profesor foreign key(id_profesor) references tblprofesores(id_profesor),
constraint fk_titulo foreign key(id_titulo) references tbltitulosuniversitarios(id_titulo),
constraint fk_institucion foreign key(id_institucion) references tblinstitucionesDeEstudio(id_institucion)
);

Lo que quiero mostrar con esto es el hecho de que en este script se muestran los tipos de datos y los nombres de los campos junto con las relaciones y restricciones.

Aqui esta el enlace para ver el script completo:
Haz click aqui

Diseño logico de la base de datos

Este es el penultimo post y aqui presentamos el diseño relacional de la base de datos, como todos saben este reestructura el diseño conceptual de la base de datos para adaptarlo de forma que pueda capturar de mejor forma los datos.

Para ver la imagen mas grande haz click aqui

Diseño conceptual de la base de datos

Hola nuevamente lectores, aquí como os prometimos les traigo el diseño conceptual de la base de datos. Este esta creado en el sencillo modelo entidad-relación. ¿Por que este y no el modelo relacional? Pues facil de responder. Dividiremos el diseño de nuestro esquema en 3 partes:

1. Diseño conceptual
2. Diseño Lógico
   
3. Implementación Física
   

El modelo entidad-relación es perfecto para representar el Diseño conceptual. Ya que en este solo queremos representar conceptos como entidades y sus relaciones entre ellas. Si usáramos directamente el modelo relacional, entonces nos someteríamos a procesos de normalizacion, especificación de dominios de campos, etc. lo cual haremos luego (claro xD).

Así que para aquellos que no conocen la simbologia de este modelo de representación de datos. Les dejare una imagen con la semantica de sus símbolos.

Ahora que ya tienen su pequeña guia aqui os dejamos nuestro primer diagrama oficial de base de datos:



Aqui el enlace para una imagen mas clara

Ahora vamos a exponer un poco acerca de este diagrama:

1- Como es un diagrama entidad-relación todavía no se usa ninguna regla de normalizacion.
2- Por esta razón los atributos multi valorados tienen su propio símbolo, y no se representan como una tabla separada.
3- Los atributos compuestos se derivan de un atributo principal, ejemplo:
ubicación y de este derivada id_país, id_ciudad, dirección
4- Se presenta cardinalidad en cada relación representada por un polígono. La cardinalidad muchos se presenta con el simbolo *.
5- Todo eso parece una tela de araña donde el centro de todo es la entidad "profesor" y le digo algo... eso mismo es.

Para la proxima... diagrama relacional. Normalizado en 1ra normal forma y tambien Boyce Codd!!! nos dara mucha lucha [la base de datos se hace grande :( ] pero haremos el trabajo.

Bye.

Analisis de requisitos Database de Docentes

En esta nueva publicación, queremos presentar el estudio de requisitos tan importante para luego hacer un análisis mas minucioso de este y extraer asi el esquema conceptual de la base de datos. Como hemos resaltado anteriormente en otras publicaciones del blog la lista de características que se integraran a la base de datos es bastante flexible y podria cambiar segun la evolucion de esta. Por ende queremos exhortar que envien sus comentarios que seran bien recibidos.

Sin mas que decir aquí presentamos el análisis de los requisitos... para el diseño de la base de datos de los docentes:

Datos personales

Nombre

Apellido

ubicación

Fecha_nacimiento

Sexo

Alias

email

IM

Web blogs

Idiomas

Certificaciones

Nombre de la certificación

Año de certificación

Tecnología

Descripción

Instituciones de estudio

Nombre de la institución

Ubicación

Años de estudio

Ubicación de la institución

Titulo(s) otorgado(s)

Fecha de entrada

Fecha de salida

Asignaturas que imparte

Nombre de la asignatura

Periodo de duración

Empresas donde ha trabajado

Nombre de la empresa

Periodo de duración

Puesto

Tecnologías usadas

Nombre de la tecnología

Años de uso

Premiaciones

Nombre premio

Concurso o competencia

Fecha de participación

Cursos extra curriculares o conferencias importantes

Nombre curso

Fecha de participacion

descripcion

*Proyectos realizados

Eso es todo por ahora. En la proxima publicacion subiremos una imagen con un esquema entidad-relacion que presenta el esquema conceptual de la base de datos.

Proyecto DataBase Docentes

Este es el primero de una serie de diversos artículos acerca de la evolución de un proyecto de base de datos. Con el tiempo iremos mostrando diagramas de la evolución del esquema de la base de datos así como "quizás" el desarrollo de un sistema que implementaría el sistema en si (aunque claro esto sucederá si mi compañero de equipo se empeña en lograrlo xD) .

Enfocándonos en el sistema, ahora les doy una definicion corta y precisa (a mi parecer) de que trata el sistema. El sistema "DataBase docentes" busca mostrar informacion acerca de los docentes de una institucion educativa. Aqui pongo una lista de las posibles características que incluirá la base de datos:

· Datos personales

· Certificaciones

· Instituciones de estudio

· Asignaturas impartidas

· Empresas donde ha trabajado

· Títulos logrados

· Premiaciones

· Intereses técnicos

Sin más que decir concluyo nuestro primer post introductorio y con el tiempo iremos actualizando.