Hoy jueves, seguimos con nuestros nuevos cursos y esta vez no enfocamos en las bases de datos. Tal como os mostramos con los resultados de la encuesta publicada anteriormente, empezaremos con algunos fundamentos de bases de datos para tener una buena base teórica e ir introduciendo poco a poco el diseño de bases de datos y finalizar con un curso dedicado MySQL junto a PHPMyAdmin (administración de las BBDD vía web) y MySQLWorkbench (IDE para la creación, diseño y administración de las BBDD desde escritorio).

Pero hoy nos centraremos en ver una introducción a las bases de datos. ¡Empecemos!

Modelos de las bases de datos

Para poder explicar algunos términos o dar definiciones exactas de las BBDD, primero hemos de saber que coexisten tres modelos diferenciados:

  • El modelo real, es lo que nosotros vemos, oímos, tocamos, olemos y probamos. En esta parte identificamos los objetos reales de nuestro mundo.
  • El modelo conceptual, es donde interpretamos los objetos reales a objetos conceptuales o ficticios. En esta parte modelizamos su estructura, las propiedades y su funcionamiento en modelos conceptuales a partir de observaciones reales.
  • El modelo físico, es la transformación de los modelos conceptuales a modelos de datos destinados a los Sistemas Gestores de Bases de Datos (SGBD) o Data Base Mamagement System (DBMS) que son los programas encargados de gestionar nuestras bases de datos.

Poniendo un ejemplo, veremos mejor su diferencia:

  • Mi coche es un SEAT IBIZA de 3 puertas con matrícula 7615DDR: objeto del mundo real.
  • Objeto Coche con las propiedades: nombre (Seat Ibiza), numeroDePuertas (3) y matricula (7615DDR): objeto conceptual con propiedades observadas del objeto real.
  • Fichero de datos, registro, campos de la BBDD que ocupa mi objeto coche “Seat Ibiza” (ficheros de datos almacenados en la BBDD de forma física, por ejemplo con MySQL como SGBD).

Como en el modelo real podemos detectar los objetos reales, observar como son, tocarlos, olerlos, etc. No hace falta entrar estudiar este apartado en detalle y por ese motivo empezaremos a estudiar el modelo conceptual.

Modelo Conceptual

En el modelo conceptual llamaremos entidad, tabla o clase a la conceptualización del objeto real. Esta entidad tendrá unas propiedades, que llamaremos atributos de la entidad y en los cuales se guardarán unos valores de atributo. En una BBDD podremos tener muchas entidades diferentes y cada una con sus atributos y valores propios.

Como norma, los nombres de las entidades se empiezan en mayúscula, y si son nombres compuestos, la primera letra de la segunda palabra también será mayúscula:

  • Persona
  • PersonaDeContacto

Para los nombres de los atributos, se escriben en minúscula, pero si son nombre compuestos, la primera letra de la segunda palabra será mayúscula:

  • nombre
  • fechaDeNacimiento

En el caso anterior, la entidad es Coche, los atributos de la entidad Coche son nombre, numeroDePuertas y matricula y finalmente los valores de los atributos de la entidad Coche son Seat Ibiza, 3 y 7615DDR.

Podríamos decir que la una entidad es una estructura (atributos y valores) para poder crear objetos a partir de ella.

Como podemos ver, con la entidad Coche podremos instanciar una nueva tupla (también llamadas filasregistros) del tipo Coche con diferentes valores en sus atributos, por ejemplo:

  • Fiat Punto, 5, 5364CFD
  • Opel Corsa, 3, 1234DDS
  • Volkswagen Golf, 5, 9867CCR

Pero primero debemos tener claro cual es el dominio de cada atributo de una entidad ya que por ejemplo si tenemos una entidad Persona, donde tenemos un atributo que sea edad, debemos especificar que sea un número entero (en teoría no puede ser un texto) y deberemos especificar que este número entero sea de un rango entre 0 a 130 (0 años para los recién nacidos menores de 1 año y hasta los 130 años, por ejemplo).

Es muy importante especificar correctamente estos dominios para evitar errores mayores que más tarde pueden ser muy laboriosos de subsanar.

Un aspecto muy importante a tener en cuenta en todas las entidades de nuestras BBDD es que tenemos que asignar un atributo como clave primaria (Primary Key o PK). Esta clave primaria será un atributo donde sus valores deben ser únicos (no podemos tener más de un registro con el mismo valor) y nos servirán para diferenciar a todos los registros de una entidad. Estas claves pueden ser de un atributo o varios atributos (claves primarias compuestas).

Para decidir que atributo podemos asignar como clave primaria, debemos hacernos esta pregunta:

¿Que atributo de la entidad es único y no se va a repetir nunca en los registros de la entidad?

Si por ejemplo analizamos la entidad Persona, tenemos:

  • El atributo edad, puede ser PK?
    • No. El atributo edad puede repetirse muchas veces en registros diferentes, por ejemplo tener a 30 personas que tengan 18 años.
  • El atributo nombre, puede ser PK?
    • No. El nombre de una persona se puede repetir en varios registros, por ejemplo podríamos tener 15 registros de personas que se llamen José.
  • El atributo compuesto nombre+primerApellido+segundoApellido, puede ser PK?
    • No. En este caso, es casi imposible tener a dos personas con el mismo nombre y los mismos dos apellidos (sería MUCHA coincidencia) pero sucede que existan dos personas o más en el mundo con el mismo nombre.
  • El atributo dni, puede ser PK?
    • No. En principio nos puede parecer un buen candidato de PK, pero el número de Documento Nacional de Identidad que es (en teoría) único para cada persona, a veces se han dado casos de números de DNI duplicados.
  • Un número único incremental o id (1, 2, 3…)?
    • Si. Normalmente, en las entidades se suelen crear unos tipos de atributos llamados identificadores o id que suelen ser los primeros en crearse. Estos se crean de tal forma que para cada nuevo registro obtenga un valor diferente y de esa forma ser realmente únicos. Para eso se suelen configurar que se generen números autoincrementales para cada nuevo registro. Por ejemplo el ID del primer registro puede ser 1, el del segundo 2, etc.

Todos los ejemplos anteriores en los cuales hemos visto que optan a ser claves primarias (PK) las llamaremos claves candidatas (únicas o UNIQUE) como por ejemplo el DNI o el Nombre+Apellidos que son claves candidatas, pero no serán PK por lo visto anteriormente. Por eso en una entidad podemos tener varias claves candidatas pero tan solo podemos tener una clave primaria (PK).

Después de observar que en la entidad Persona tiene las claves candidatas nombre+primerApellido+segundoApellido y dni, debemos analizarlas más detenidamente. Podemos ver que, aunque sea casi imposible, la clave candidata nombre+primerApellido+segundoApellido podría tener duplicidades en registros y por eso la descartamos como PK, pero quedaría como candidata. Ahora la única que nos queda es la clave candidata dni. Aunque parezca que los números de dni son totalmente únicos, se han dado casos de duplicidades de números de dni (y cuando pasa esto, se corrige inmediatamente). Por ese motivo, y de forma probable, podríamos tener también duplicidades en registros.

Entonces, si no tenemos ninguna clave candidata que opte de forma segura a ser clave primaria, ¿que podemos hacer?. ¡Pues vamos a crearla!

De facto, los diseñadores de bases de datos, suelen tener una o varias claves candidatas (claves que, en teoría, son únicas y no se repiten) en una entidad, pero son ellos los que crean un nuevo atributo en cada entidad para que sea realmente único para cada registro (PK). Son los llamados atributos o campos id.

Un atributo id se crea de tal forma para que sea un valor numérico (número entero) que empieza normalmente con el 1 y se incrementa automáticamente en una unidad con cada registro nuevo. Así por ejemplo, en la clase persona podríamos tener la siguiente estructura de entidad o tabla:

Persona
 idPersona (PK)  nombre  apellido1  apellido2  dni (UNIQUE)  edad
1  José  Pérez  Ruíz  45637198B  22
2  Pedro  Martínez  Fuentes  75649345T  35
3  María  Salomón  Puentes  29763451F  19

 

Así podemos observar como nos quedaría el diseño de la entidad Persona de nuestra BBDD.

Los diseñadores de bases de datos necesitaban tener un lenguaje común entre ellos para poder describir y diseñar las entidades y otros elementos de una base de datos. Eso se debe a que si por ejemplo, un diseñador creaba una entidad en ese lenguaje, y más tarde necesitaba enviar a otro diseñador ese mismo diseño, este debería entenderlo sin ningún problema, igual que las matemáticas. Si a todo el mundo le preguntamos 2+2, todos dirán 4.

Por eso, desde el año 2005 tenemos un lenguaje unificado de modeladoUnified Modeling Language (UML) el cual es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un “plano” del sistema (modelo), incluyendo aspectos conceptuales tales como procesos, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.

Aquí os dejo un vídeo de nuestro canal de Youtube para que podáis ver como descargar el programa ArgoUML el cual lo utilizaremos más adelante para diseñar y dibujar las entidades de nuestras BBDD. Por ahora solo debéis quedaros con los conceptos básicos de que como se dibuja una entidad y como se añaden los atributos. Más adelante os explicaremos más en profundidad como usar ArgoUML.

Hasta aquí esta primera entrega. El próximo jueves estudiaremos como se relacionan las entidades de nuestra BBDD y así más tarde relacionar datos de una instancia con otra totalmente diferente.

Si tenéis alguna duda o problema, podéis escribir un comentario en esta entrada y os contestaremos lo antes posible. ¡Y suscribíos a nuestro canal de Youtube!

Saludos,

Info | Wikipédia