Nociones Basicas del diseño

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.

Un primer ejemplo.
Vamos ver un primer ejemplo, que nos ayudará a llevar a la práctica todo esto y a
introducir el modelo “Entidad-Relación”. Supondremos que nos proponen el siguiente problema:
 

“Se desea informatizar un centro de estudios de pequeño tamaño.
Interesa controlar exclusivamente los asuntos académicos: qué
alumnos tenemos, qué cursos/asignaturas han realizado, qué
profesores tenemos en plantilla, quién ha impartido cada uno de los cursos, etc”.

Estas serían las indicaciones que nos daría el cliente (o que nosotros pensaríamos, si lo realizamos para nosotros mismos). Ahora tendríamos que pensar si vemos que falta algo (y preguntar al cliente, si procede, cosas como si desea guardar la dirección y demás datos postales de los alumnos y de los profesores, o si quiere saber la nota que cada alumno obtuvo en cada curso) o incluso si sobra algo (porque resulte demasiado difícil de llevar a cabo -¿difícil, para nosotros?... lo dudo-).

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 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...

Introducción

Introducción. 

 

Conceptos básicos.

En el sentido más amplio, se podría considerar que una base de datos es
simplemente un conjunto de información.
En un ordenador, esta información normalmente será básicamente una serie de
“fichas”.
Por ejemplo, una base de datos muy sencilla podría ser una agenda de direcciones
en la que anotemos datos de nuestros amigos. Tendríamos una ficha para cada uno
de estos amigos. En cada ficha, a su vez, existirá una serie de apartados, como el
nombre, la dirección, el teléfono, etc.
Esto nos permite introducir dos primeros conceptos que utilizaremos: cada una de
estas “fichas” recibe el nombre de  “registro”, y cada uno de los “apartados” que
componen las fichas se llama “campo”.
El conjunto de las fichas (registros) forma un “bloque” de información, que
llamaremos “tabla”, y que se suele representar escribiendo cada ficha (registro) en
una fila y cada apartado (campo) en una columna, así:

 

Pero en la práctica, una “base de datos” real suele estar formada por más de una
tabla. Por ejemplo, la base de datos que utiliza una empresa “normal” para su
gestión deberá almacenar datos sobre clientes, proveedores, artículos, facturas, etc.
Cada uno de estos “bloques” de datos será una tabla, y estas tablas estarán
relacionadas entre sí (por ejemplo: un artículo será suministrado por un cierto
proveedor, y ese artículo aparecerá en ciertas facturas, cada una de las cuales
corresponderá a un cierto cliente).

En este blog veremos las nociones básicas de cómo se crea y se maneja una base de
datos: cómo diseñar las tablas y las relaciones, cómo introducir los datos y como
buscar información en la base de datos. Intentaré aplicarlo a alguna de las bases de
datos más habituales, como Access para Windows (para quien tenga un ordenador
“moderno”) o dBase III+ (para los que tengan un ordenador “antiguo”). También
daré unas nociones básicas de lenguaje SQL, un lenguaje de consulta a bases de
datos que la mayoría de los sistemas actuales permiten utilizar.