Etapas básicas del diseño
El primer paso antes de crear una base de datos es pararse a pensar. Ni más ni menos. Si en la programación es muy peligroso eso de empezar a teclear según aparece una idea (a pesar de que hay bastante gente que lo hace, y alguno lo hace incluso bien… si el programa es corto), en la creación de bases de datos es muy raro que salga bien.
El segundo paso recomendable es ir anotando las ideas según surgen. Cuando creemos que ya está todo, deberíamos volver a leer todas las notas que habíamos tomado, porque eso nos ayudará a tener una visión de conjunto y a notar si falta algo que no hayamos previsto inicialmente.
El tercer paso será empezar a dibujar garabatos que representen esa información. Para ello veremos por encima un modelo llamado “Entidad-Relación”. El dibujo nos ayudará a tener una nueva versión de conjunto, mucho más fácil de seguir y más completa que las anotaciones. Aquí se verán todavía mejor las carencias y las incongruencias que puedan existir.
El cuarto paso será convertir este dibujo en las tablas. Este paso puede ser casi totalmente mecánico. Por ejemplo, la conversión del modelo Entidad-Relación (el que veremos) a una base de datos relacional (las que normalmente manejaremos) es casi inmediato.
Se acabó el diseño. Podríamos añadir un quinto paso que sería la introducción de los datos y la creación de una serie de estructuras auxiliares, como formularios, consultas o informes, que ya veremos.
Pasamos a desglosar en bloques de información. De momento todavía no hablaremos de tablas, sino de “entidades” (un nombre más ambiguo pero más adecuado) y de “relaciones” entre estas entidades.
En nuestro caso, las “cosas” (entidades) que tenemos son básicamente éstas:
- Alumnos.
- Cursos.
- Profesores.
Y las relaciones que hay entre estas entidades son:
- Los profesores IMPARTEN cursos.
- Los alumnos ASISTEN a cursos.
- (Indirectamente, los alumnos y los profesores también están relacionados: un alumno ha asistido a un curso que ha impartido un cierto profesor; esta relación ya queda reflejada a partir de las otras dos, así que no es necesario detallarla).
Aun comentaremos algo más sobre las relaciones. Una característica importante de las relaciones es su “cardinalidad”: por ejemplo, en la relación de que “los alumnos asisten a los cursos”, es importante si a cada curso sólo puede asistir un alumno o varios, y si un alumno puede asistir a un solo curso o a varios.
Tendremos cuatro posibilidades:
- Que cada alumno asista a uno y solo uno de los cursos (se expresa como 1:1 -uno a uno-)
- Que cada alumno pueda asistir a muchos cursos, pero en cada curso sólo puede haber un alumno (1:M -uno a muchos-)
- Que cada alumno pueda asistir a un único curso, pero pueda haber varios alumnos en un curso (M:1 -muchos a uno-).
- Que cada alumno pueda asistir a varios cursos, y en cada curso pueda haber varios alumnos (M:M -muchos a muchos-)
En nuestro caso, la relación “asistir” es una relación de “muchos a muchos” (M:M). Podríamos preguntarnos la cardinalidad de la otra relación (“los profesores imparten cursos”). En este caso, cada profesor puede impartir varios cursos, y supondremos que cada curso es impartido por un único profesor (estoy dando por supuesto que se considera distinto un curso de “Bases de Datos” impartido en una fecha y otro de la misma temática pero impartido en fecha distinta). Se trataría de una relación “de uno a muchos” 1:M.
Una observación: en las relaciones es importante el sentido en el que se leen. Por ejemplo, la relación “los profesores imparten cursos” es una relación 1:M (uno a muchos), mientras que la relación opuesta “los cursos son impartidos por profesores” es una relación M:1 (muchos a uno).
Estas relaciones que hemos comentado son “relaciones binarias” (entre dos entidades). Por el carácter introductorio de este texto, no entraremos en las relaciones que engloban más entidades (como las ternarias), ni en cierto tipo de restricciones (como las de existencia o valor no nulo), ni en generalizaciones, asociaciones ni agregaciones… al menos por ahora…