A buscar M!nas: MSAccess - ampliando VB.net

Buenas otra vez!

Me he pasado el finde descansando y vagueando, que ya tocaba! (13/10/12)

Pero hoy es lunes, así que volvemos a la carga con el blog. Además empezamos la parte de programación.

En esta entrada ampliaremos el juego, usando ADO.net.

ADO.net

ADO.net es un objeto que el ".net" provee, con la función de conectar a las bases de datos sin demasiadas dificultades.

Por así decirlo, crea una capa extra entre el motor de la base de datos y la aplicación .net (así como hicimos con Java hace tiempo, pero de manera nativa).

Hay una serie de objetos que segregan de la utilización de ADO, que son:

• OleDbConnection: provee la conexión
• OleDbCommand: contiene sentencias SQL, sirve para lanzarlas
• OleDbDataReader: se usa para obtener los datos de las sentencias.

Una visualización de ejemplo: supongamos que al iniciar el juego de VB.net, éste conecta con la base de datos y ejecuta un SQL. El esquema sería algo así como indica la img1

img1

El evento onLoad tiene su recorrido en naranja: así, se puede ver cómo, usando los objetos de ADO.net accedemos a la base de datos, y extraemos datos, los cuales serán tratados con OleDbDataReader.

Haciendo un símil con PHP, el OleDbCommand equivaldría al mysq_query(), mientras que el OleDbDataReader equivaldría al mysq_fetch_array().


Diseño de consultas

El siguiente paso es diseñar todas las consultas que nos pudieran hacer falta. Aquí enumeraré unas cuantas imprescindibles:

• Comprobar si existe un usuario
• Crear un nuevo usuario
• Insertar un registro

Tal como quedó el modelo relacional, definiríamos las sentencias así:

• select count(*) from usuario where nick='';
• insert into email(email) values(''); insert into usuario(nick, nombre, apellido1, apellido2, idE, password) values('', '', '', '', select max(idE) from email, '');
• insert into estadistica(gana, tiempo, dificultad, opcion, autenticacion, minas, clicks) values('', '', '', '', '', '', '', ''); insert into juego(nick, id_estadistica, fecha) values('', select max(id_estadistica) from estadistica, '');

Desde luego estas consultas son las realmente básicas. No he puesto ningún dato porque de momento aún tenemos que ver cómo rellenaremos estas sentencias.

NOTA: cometí un error (como no...) cuando describía las tablas: la columna "minas" sirve para almacenar el número de minas que el usuario tenía marcadas cuando el juego terminó.

Hacer que funcione

El último paso antes de finalizar esta entrada es conectar todo; tenemos el MSAccess, el VB.net y el ADO.net. Es el momento de conectarlo todo!

Para ello, el objeto OleDbConnection necesita lo que se denomina "cadena de conexión". Ésta es un String que contiene información parametrizada sobre cómo y con qué conectará el objeto.

La cadena de conexión de ADO.net para MSAccess es la siguiente:

Provider=Microsoft.ACE.OLEDB.12.0;Data Source=SRC;Persist Security Info=False;

Las partes en negrita son variables. SRC indica la ruta física donde está la base de datos, y False indica si la conexión ha de ser persistente (por defecto siempre a false con MSAccess).

Ahora abrimos nuestro proyecto de VB.net, y añadimos las siguientes líneas en BX_module:

    Public con As OleDbConnection
    Public cn As String = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" + Application.StartupPath + "\BuscaminaX.accdb;Persist Security Info=False;"
    Public cmd As OleDbCommand

Aquí definimos los dos objetos fijos que usaremos para tratar nuestra base de datos. Dos anotaciones: seguramente tendréis que importar el dominio System.Data.OleDb. Para ello escribid al comienzo del módulo:

"Imports System.Data.OleDb"

Por otra parte, tenéis que copiar la base de datos "BuscaminaX" a la carpeta de la aplicación ("/bin/debug").

El siguiente paso es definir tres funciones globales para nuestra aplicación:

• Una función de conexión
• Una función de ejecución de SQL (insert, update, delete)
• Una función de consulta SQL (select)

Las podemos definir así:

#Region "SQL FUNCTIONS"

    Public Sub Conectar()

        BX_module.con = New OleDbConnection(cn)

    End Sub

    Public Sub Lanzar(ByVal sql As String, ByRef r As OleDbDataReader)

        BX_module.con.Open()

        cmd = New OleDbCommand(sql, BX_module.con)

        r = cmd.ExecuteReader()

    End Sub

    Public Sub Ejecutar(ByVal sql As String)

        Dim command As New OleDbCommand(sql, con)

        Try

            command.Connection.Open()
        Catch ex As Exception
        End Try

        command.ExecuteNonQuery()

        command.Connection.Close()

        command.Dispose()

        command = Nothing

        con.Close()

    End Sub

#End Region

Vamos a analizar un poco el código:

 - Conectar() instancia un nuevo OleDbConnection usando la cadena de conexión "cn".

 - Lanzar(sql, r) abre la conexión, instancia un nuevo OleDbCommand con "sql" y "con", y rellena "r". Nótese que para que los cambios en "r" sean persistentes, pasamos la variable por referencia ("ByRef") y no por valor ("ByVal")

 - Ejecutar(sql) crea un nuevo OleDbCommand (ya que luego será destruído), y ejecuta la sentencia SQL pasada.

Para leer los datos que devuelve lanzar debemos hacer algo similar a PHP (por ejemplo). Concretamente:

Lanzar(ret, r)

Do While r.Read
    'cosas. Se accede por "r(n)", donde n es un entero mayor o igual que 0
 Loop

con.Close()

Y así es cómo accedemos a los datos desde VB.net.

El siguiente paso es hacer un sistema de registro para cuando empieza el juego. También (después) crearemos una pantalla con estadísticas.

Para la pantalla de inicio de sesión, crearemos una nueva "SplashScreen". La llamaremos "LogIn.vb". De nuevo la preparamos borrando todo el contenido, y colocamos varios campos rellenables; tal que así:

img2

Ahora debemos esquematizar la comprobación de datos. Para ello haremos lo siguiente, teniendo en cuenta que un usuario anónimo no tendrá password, mientras que uno registrado sí; y tomando como supuesto que el usuario pulse "next" (el otro caso lo vemos ahora)

SI nick NO vacío
    recoges datos de DB
SINO
    error
FIN

SI datos(pass) NO vacío
    SI pass vacío
       error
    SINO
        SI datos(pass) = pass
            ok!
        SINO
           error
    FIN
SINO
    ok!
FIN    

Se puede ver una gran cantidad de "IF". Ahora os explicaré lo que yo llamo "filtrar por return". Esta técnica quizás no sirva para acortar demasiado el código, pero sirve para evitar tantas identaciones.

El sistema es el siguiente: se supone el "peor" caso. Si se cumple salimos, sin más (terminamos el sub, retornamos un valor de control...).

En la siguiente línea, ya tenemos controlado el caso, por tanto no hace falta un "ELSE".

Aplicando este concepto, podemos hacer:

SI nick vacío
    error(SALIR)
FIN

SI datos(pass) NO vacío
  SI pass vacío
    error(SALIR)
  FIN
SINO
  SI datos(pass) NO = pass
    error
   FIN
FIN

sigue

El siguiente caso a contemplar es el de crear un nuevo usuario. Para ello los pasos a seguir son:

 - Comprobar si todos los datos están introducidos
 - En caso que lo estén, comprobar si existe el usuario registrado
 - En caso que no exista, introducimos los datos.

Crearemos dos funciones principales para sendas tareas. Podrían ser algo así:

#Region "LogIn"
    Public Function nextStep() As Boolean
        Dim r As OleDbDataReader
        Dim pass As String

        If LogIn.TextBox1.Text.Length = 0 Then
            Return False
        End If

        BX_module.Conectar()
        Lanzar("select nick, password from usuario where nick ='" + LogIn.TextBox1.Text.ToString + "'", r)
        r.Read()

        Try
            pass = r(1)
        Catch ex As Exception
            pass = ""
        End Try

        BX_module.con.Close()

        If pass <> "" Then
            If LogIn.TextBox2.Text.ToString = "" Then
                Return False
            ElseIf LogIn.TextBox2.Text.ToString <> pass Then
                Return False
            End If
        Else
            If pass <> LogIn.TextBox2.Text.ToString Then
                Return False
            End If
        End If

        Return True
    End Function

    Public Function newUser() As Boolean
        Dim r As OleDbDataReader
        Dim cont As Integer
        Dim idE As Integer

        If LogIn.TextBox3.Text = "" Or _
           LogIn.TextBox4.Text = "" Or _
           LogIn.TextBox5.Text = "" Or _
           LogIn.TextBox6.Text = "" Or _
           LogIn.TextBox7.Text = "" Then
            Return False
        End If

        BX_module.Conectar()
        Lanzar("select count(*) from usuario where nick ='" + LogIn.TextBox4.Text.ToString + "' and idE = (select idE from email where email = '" + LogIn.TextBox5.Text.ToString + "')", r)
        r.Read()

        Try
            cont = r(0)
        Catch ex As Exception
            cont = 0
        End Try

        BX_module.con.Close()

        If cont <> 0 Then
            Return False
        End If

        BX_module.Conectar()
        Lanzar("select max(idE) from email", r)
        r.Read()

        Try
            idE = r(0) + 1
        Catch ex As Exception
            idE = 1
        End Try

        BX_module.con.Close()
        Ejecutar("insert into email(idE, email) values(" + idE.ToString + ", '" + LogIn.TextBox5.Text.ToString + "')")
        BX_module.Conectar()
        Lanzar("select idE from email where email = '" + LogIn.TextBox5.Text.ToString + "'", r)
        r.Read()
        Ejecutar("insert into usuario([nick], [nombre], [apellido1], [apellido2], [idE], [password]) values('" + LogIn.TextBox4.Text.ToString + "', '" + LogIn.TextBox6.Text.ToString + "', '" + LogIn.TextBox7.Text.ToString + "', '" + LogIn.TextBox8.Text.ToString + "', " + r(0).ToString + ", '" + LogIn.TextBox3.Text.ToString + "')")
        BX_module.con.Close()
        Return True
    End Function
#End Region

Ahora viene enlazar los valores de retorno al módulo principal. Esto lo haremos en dos partes, de manera que:

 - Crearemos una variable pública en LogIn.vb, de manera que el resultado de la función se guardará ahí.
 - Mientras la variable anterior sea "false", mostraremos la pantalla principal.

Esto lo hacemos así:

a) LogIn.vb

    Public hand As Boolean = False

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Me.hand = BX_module.nextStep()
    End Sub

    Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click
        Me.hand = BX_module.newUser()
    End Sub

b) BuscaminaX.vb -> BuscaminaX_onLoad

        Do
            LogIn.ShowDialog()
        Loop Until LogIn.hand

Con esto damos por terminada la parte de Programación en VB.net

Así, en la próxima entrada trataremos la gestión de consultas desde MSAccess.

Pido disculpas por la tardanza; repito que estuve MUY liado.

Espero poder seguir escribiendo más a menudo!

Saludos y,

¡Hasta la próxima!

NOTA: algunos retrasos

Buenas!

Estoy muy muy liado...  voy hasta arriba en el trabajo durante esta semana, y aún tengo que adelantar la parte de VB.net

No obstante intento sacar ratos libres para escribir. Tened paciencia, espero terminar la siguiente entrada pronto!

Saludos y

Hasta la próxima...

A buscar M!nas: MSAccess - SQL

Buenas!

Empezamos por fin la parte de programación. Esta sección ocupará tres entradas, en las cuales ampliaremos todo el proyecto.

Pues bien, empecemos ya mismo con la primera parte: el SQL.

La primera tarea que tenemos que hacer es crear algunas sentencias SQL para crear las tablas, partiendo del modelo normalizado de la anterior entrada (lo siento, se me pasó un error; éste es el modelo bueno):

usuario(nick, nombre, apellido1, apellido2, idE, password) 

email(idE, email)

estadistica(gana, tiempo, dificultad, opcion, autenticacion, minas, clicks, id_estadistica)
juego(nick, id_estadistica, fecha)

CREATE TABLE usuario(

    nick varchar(50),

    nombre varchar(50),

    apellido1 varchar(50),

    apellido2 varchar(50),

    idE int,

    password varchar(16)

);

CREATE TABLE email(

    idE int,

    email varchar(100)

);

CREATE TABLE estadistica(

    gana int,

    tiempo int,

    dificultad int,

    opcion int,

    autenticacion int,

    minas int,

    clicks int,

    id_estadistica int

);

CREATE TABLE juego(

    nick varchar(50),

    id_estadistica int,

    fecha varchar(14)

);

He querido hacer la parte de creación desde SQL, y dejar la parte de las restricciones. Esta parte la veremos con MSAccess directamente (así variamos un poco las cosas).

Pues bien, vamos a crear nuestra base de datos.

Primero abrimos MSAccess, seleccionamos "Nueva base de datos en blanco", le cambiamos el nombre (yo le pondré "BuscaminaX"), y apretamos "enter" o le damos a "crear" (img1).

img1

Ahora tendremos una tabla por defecto, tabla1. De momento no le prestamos atención.

Vamos a la sección "Crear", y de ahí vamos a "Diseño de consulta" (img2).

Nos saldrá una ventana nueva y una ventana emergente. Cerramos la ventana emergente y pulsamos, en el menú, la opción "SQL" (img3).

img2

Borramos el contenido ("SELECT;") y copiamos, una por una, las sentencias de creación. Tras escribir una sentencia pulsamos el botón de ejecutar. Esto hará que se creen las tablas.

img3

Una vez ejecutadas todas las sentencias deberemos tener algo similar a la "img4".

La siguiente tarea es asignar las PK. Para ello pulsamos en una tabla, y se nos abrirá el editor. Vamos a la pestaña inicio y pulsamos el icono "ver". Seleccionamos los campos necesarios y pulsamos la opción "Clave principal (img5). Repetimos esto para todas las tablas, y ya tendremos nuestras PK.

img4

img5

img6

Finalmente nos falta establecer las FK. Para ello vamos a la sección "Herraminentas de base de datos" y pulsamos sobre "Relaciones". Esto nos abrirá una nueva ventana con una nueva ventana emergente. Seleccionamos todas las tablas y le damos a intro (o a agregar). Veremos cómo aparecen en la ventana; hecho esto cerramos la ventana emergente, y nos quedará algo como la img6.

Ahora arrastramos los campos: de PK a FK (por ejemplo, de email.idE a usuario.idE). Recordad que debéis cerrar y guardar el resto de ventanas (MSAccess nos dará la lata continuamente con esto).

Al intentar crear una FK nos saldrá un cuadro; revisamos que los atributos sean los correctos, y marcamos "Exigir integridad referencial" (img7).

img7

Cuando todas las relaciones estén completadas, nos quedará el panorama como en la img8.

img8

Siento la ingente cantidad de fotos, la verdad es que no sabía muy bien como cuadrarlas...

Pero bueno, creo que no queda tan mal :-P

Hemos terminado la parte de SQL (por ahora). Solo tenemos que guardar nuestra base de datos y podemos cerrar MSAccess hasta la entrega de gestión (dentro de dos entregas).

En la próxima veremos cómo ampliamos nuestro juego de VB.net para hacer que todo esto sirva para algo.

¡Hasta la próxima!

A buscar M!nas: MSAccess - normalización

Buenas!

Nos adentramos de lleno en la fase final de la construcción de nuestra base de datos primitiva.

Así, hoy veremos el paso final antes de implementar nuestro modelo; la normalización.

Este proceso, como su nombre indica, "normaliza" el modelo relacional, de manera que será más definido y útil.

El proceso es gradual, es decir, no se puede llegar a una forma normal (FN) si no está en la FN anterior (y así recursivamente...)

Conceptos previos:

Antes de entrar en el proceso, vamos a definir unos conceptos, que nunca viene mal:

• O: durante esta entrada, para referirnos a un conjunto de valores originales usaremos la letra "o" mayúscula (no confundir con cero).
• I: se trata de un conjunto imagen.
• Intención: es la descripción "fija" de una tabla. Contiene los descriptores de la tabla así como las restricciones. Se puede representar como R(A1, A2, A3, ... , An)
• Extensión: es el conjunto de tuplas ("filas") de una tabla en un momento determinado.

Ahora que tenemos los términos básicos definidos, podemos pasar a definir qué es una dependencia funcional:

• Dependencia funcional: Restricción sobre una relación con intención R(A1, A2, A3, ... , An) que representa un esquema {x} -> {y} donde {x} e {y} son subconjuntos de la intención que garantiza que dado un valor de {x}, es determinado de manera única un valor de {y}*.

* Esto se puede representar (de un modo aproximado) como;

[{x}, {y} c (A1, A2, A3, ... , An) | Xi <-> Yj]

Vista esta pequeña introducción, podemos pasar a la normalización:

Normalización:

Como comentaba, se trata de un proceso progresivo. De esta manera, empezaré con la primera forma normal (1FN) e iré avanzando hacia modelos más normalizados. Empecemos:

• 1FN: se dice que una relación está en 1FN si ningún atributo de la relación es en si mismo una relación, es decir, si todo atributo de la relación es atómico, no descomponible y no es un grupo repetitivo (solo tiene ciertos valores)

Ejemplificando: supongamos la siguiente tabla: Alumno(DNI, nombre, notas). En este caso, las notas son algo no atómico, descomponible y tiene parte de grupo repetitivo. Ampliando la información, sería:

 - No atómico: "notas" es un registro que puede estar repetido dentro de un mismo registro. Por ejemplo para el DNI1 puede haber algo así como "castellano primer trimestre: 5, inglés primer trimestre..." dentro del mismo registro.

 - Descomponible: se puede dividir en varias secciones. Por ejemplo: nota, asignatura, trimestre.

 - Grupo repetitivo: las asignaturas, la nota y el trimestre son de por sí grupos repetitivos.

Alumno(DNI, nombre, notas) ==> Alumno(DNI, nombre, asignatura, nota, trimestre)

Al normalizar se ha tenido que expandir la PK, para que no haya duplicados.

• 2FN: se dice que una relación está en 2FN si está en 1FN y todo atributo no clave depende funcionalmente, en forma completa de la PK.

Esto quiere decir que todo aquel atributo que dependa de algo que no sea la TOTALIDAD de la PK de la tabla tendrá que ser modificado, de manera que ese atributo pasará a ser una tabla. La tabla que fue normalizada incorporará como FK la PK de la nueva tabla.

• 3FN: se dice que una relación está en 3FN si está en 2FN y ningún atributo no clave depende funcionalmente de ningún otro conjunto de atributos no clave.

¿Qué significa esto? Puede parecer algo lioso, pero de vez en cuando se ve. Veamos un ejemplo:

Direccion(ID, calle, ciudad, provincia)

En este caso (y refiriéndonos a un modelo local, es decir, suponiendo que solo se tiene en cuenta un país) sabiendo la ciudad se sabe la provincia. Por eso, esta tabla no está en 3FN.

Direccion(ID, calle, ciudad, provincia) ==> Direccion(ID, calle, idCiudad)  Ciudad(ciudad, provincia)

Se crea una nueva tabla y se asigna una nueva FK

• FNBC: esta forma normal es "especial", ya que está a caballo entre la 3FN y la 4FN. Normalmente se acepta una base de datos normalizada hasta la FNBC. No obstante nosotros veremos hasta la 5FN. 

La FNBC dice que dada una dependencia funcional {x} -> {y}, todo elemento de "x" es considerado como clave candidata.

Una definición así cuesta ver, así que dejo un ejemplo:

Notas(DNI, codAsig, codMatr, nota)

En esta tabla, DNI y codAsig son la PK. No obstante, el atributo "codMatr" es una clave candidata (es decir, podría servir como PK). Así, surgen cuatro opciones para normalizar esta situación:

a) Notas(DNI, codAsig, nota)

    Alumno(DNI, codMatr)

b) Notas(DNI, codAsig, nota)

    Alumno(codMat, DNI)

c) Notas(DNI, codAsig, nota)

    Alumno(codMat, DNI)

d) Notas(DNI, codAsig, nota)

    Alumno(DNI, codMat)

• 4FN: para saber si una relación está en 4FN tenemos que comprobar que no existan DMI (Dependencia Multievaluada Independiente) y está en FNBC.

Una DMI se define como:

Sea "R" una relación con esquema R(A1, A2, A3, ..., An), y siendo {x}, {y} y {z} atributos de "R", se dará la DMI {x} ->> {y} si y solo si el conjunto de valores posibles de {y} para un par {x, z} depende únicamente del valor de "x" y es independiente del valor de "z".

Visto desde el punto de vista relacional, significa simplemente que las relaciones "n-arias" pasan a ser "n" relaciones con relación "n : n".

• 5FN: una relación está en 5FN si y solo si está en 4FN y cumple que no tiene PK descomponible.

Para verlo mejor, un ejemplo:

Profesor(ID, nombre)

Asignatura(ID, nombre)

Centro(ID, nombre)

Ensenanza(IdPro, IdAsi, IdCen)  ==> PA(IdPro, IdAsig) PC(IdPro, IdCen)

Ahora ya sabemos en qué consiste normalizar; vamos a aplicarlo a nuestro modelo:

usuario(nick, nombre, apellido1, apellido2, email, password)
estadistica(gana, tiempo, dificultad, opcion, autenticacion, minas, clicks, id_estadistica)
juego(nick, id_estadistica, fecha)

•  1FN: en la tabla estadistica tenemos varios grupos repetitivos: "gana", "dificultad", "opcion", "autenticacion", "minas"). A continuación se describen los grupos repetitivos:

 - Gana:

   * Sí (1)

   * No (2)

 - Dificultad:

   * Fácil (1)

   * Medio (2)

   * Difícil (3)

- Opción:

   * Opción 1 (1)

   * Opción 2 (2)

 - Autenticación:

   * Registrado (1)

   * Anónimo (2)

 - Minas:

   * 10 (1)

   * 40 (2)

   * 99 (3)

Para deshacer los grupos repetitivos trasladamos todos los valores a numéricos, empezando siempre por 1 y llegando hasta el último valor disponible. Éstos valores se colocan arriba entre paréntesis.

• 2FN: El modelo está en 2FN.
• 3FN: Se puede apreciar en la tabla usuario cómo el campo "email", si no es nulo sirve para identificar a un usuario. Por ello realizamos la siguiente modificación:

usuario(nick, nombre, apellido1, apellido2, email, password) ==> usuario(nick, nombre, apellido1, apellido2, idE, password) email(idE, email)

• FNBC: Se ha eliminado la clave candidata (email) en la tabla usuario (realmente no era clave candidata puesto que podría ser un dato vacío). Por tanto, estamos en FNBC.
• 4FN: Está en 4FN
• 5FN: Está en 5FN.

De este modo, tenemos por fin nuestro modelo relacional normalizado, siendo el siguiente:

usuario(nick, nombre, apellido1, apellido2, idE, password) 

email(idE, email)

estadistica(gana, tiempo, dificultad, opcion, autenticacion, minas, clicks, id_estadistica)
juego(nick, id_estadistica, fecha)

Con esto dejamos la base preparada para el próximo paso: la programación.

Así, en la próxima entrega veremos cómo pasar este esquema al SQL, y más adelante haremos las ampliaciones necesarias en nuestro juego de VB.net.

Espero no se os haya hecho muy pesada la lectura.

¡Hasta la próxima!

A buscar M!nas: MSAccess - modelo relacional

Buenas!

Entramos de lleno ya en el tema del diseño. Para diseñar una buena base de datos, partiendo del modelo E - R expuesto en la entrada anterior, necesitamos realizar un proceso de "relacionalización".

Y, ¿En qué consiste? Básicamente se trata de "pasar" las tablas a notación relacional (una sintaxis más cercana al SQL).

Pero, sin embargo, debemos (o deberíamos) aplicar una serie de normas y patrones antes y después de hacer la transformación. Aplicarlas sirve para preparar la futura base de datos para que sea más sencilla de comprender, y a la larga que todo sea más fácil e intuitivo.

PRETECAR

A los pasos previos a la creación del modelo relacional las conozco como PRETECAR (es un acrónimo de Previa REgla de Transformación del Esquema Conceptual A Relacional).

De estas reglas hay dos (PRETECAR 1 y PRETECAR 2). A saber:

• Eliminación de atributos múltiples
• Eliminación de atributos compuestos

La primera casi nunca tendremos que aplicarla, mientras que la segunda es más usual tener que aplicarla. Explico más a fondo las reglas:

Un atributo múltiple es aquel que puede tener más de un valor. Es decir, un atributo que pueda ser tomado como lista o array.

Un ejemplo sería el caso en que tenemos la siguiente tabla:

LIBRO

ISBN

Título

Autor

En este caso,  un libro puede estar escrito por varios autores. Así, deberíamos aplicar la PRETECAR 1.

Un atributo compuesto es todo aquel que pueda ser divisible, como por ejemplo "Dirección", "Nombre completo"...

Ahora ya sabemos cuál es el problema que eliminan las PRETACAR 1 y 2. Pero falta saber cómo lo hacen:

• PRETECAR 1: Extrapolamos el atributo múltiple a una entidad débil por existencia, dependiente de la clase de la que se segrega. Ambas clases guardarán una relación "n : n".
• PRETECAR 2: Se crean los atributos que fueren necesarios, y se vuelve a comprobar la PRETECAR 2 (a veces los elementos compuestos tienen "dentro" más elementos compuestos).

Una pequeña aclaración: una entidad débil por existencia es aquella que depende de otra, pero tiene "sentido" que exista de por sí. Una entidad débil por existencia es, en el caso anterior (LIBRO), Autor, ya que es un atributo múltilpe, y por PRETECAR 1 sería una entidad débil por existencia.

Como se ve, el término "Autor" y lo que ello representa tiene significado; pero en este caso está supeditado a la clase LIBRO.

El otro caso de entidad débil (entidad débil por identificación) es aquella que depende de la entidad fuerte para ser un ente. Es el caso de la relación "Factura - Línea". En este caso, "Línea" sería la entidad débil, y no tiene razón de ser si no se relaciona con una factura.

RETECAR

El siguiente paso, tras preparar nuestro modelo E - R para pasar a modelo relacional, es hacerlo mediante las llamadas RETECAR. Son sencillas reglas que permiten que el paso a modelo relacional sea estándar y rápido. Son:

• RETECAR 1: Todas las entidades presentes en el esquema conceptual se transforman en relaciones en el esquema relacional, manteniendo el número y tipo de atributos así como el identificador.
• RETECAR 2: Se divide en tres opciones:
• RETECAR 2.1: Si en una relación binaria el grado es "1 : 1" y ambas son obligatorias, entonces, se procede:
• RETECAR 2.1.1: Si ambas tienen el mismo identificador se creará una sola tabla formada por la agregación de los atributos de ambas entidades, siendo la PK el identificador común.
• RETECAR 2.1.2: Si ambas tienen identificadores diferentes, cada entidad se transformará en una tabla, usando la RETECAR 1, y cada tabla tendrá como PK el identificador de la propia entidad, y como FK la PK de la otra tabla.
• RETECAR 2.2: Si en la relación binaria "1 : 1" hay una entidad obligatoria y la otra opcional, cada entidad se transformará en una tabla usando la RETECAR 1, y adicionalmente se procederá por una de estas dos vías:
• RETACAR 2.2.1: El identificador de la opcional pasa como FK a la entidad obligatoria
• RETECAR 2.2.2: Se construye una nueva tabla correspondiente a la relación formada por los atributos identificadores de las dos entidades y siendo la PK el identificador de la entidad opcional.
• RETECAR 2.3: Si ambas entidades son opcionales, se crean sendas tablas por RETECAR 1, añadiendo una de estas dos posibilidades:
• RETECAR 2.3.1: Los id. de cada entidad pasan a formar parte como FK de la otra tabla.
• RETECAR 2.3.2: Se construye una nueva tabla correspondiente a la relación cuyos atributos serán los identificadores de las dos entidades, y la PK será uno de los dos identificadores de la tabla.
• RETECAR 3: Se divide en dos opciones:
• RETECAR 3.1: Si es una relación binaria de grado "1: n" o "n : 1", ambas entidades participan obligatoriamente o la entidad de grado "n" participa de manera opcional, cada entidad se transformará en una tabla por RETECAR 1, y el identificador de la entidad de grado "1" pasará a ser FK de la tabla de grado "n"
• RETECAR 3.2: Si es una relación binaria de grado "1: n" o "n : 1", siendo ambas entidades opcionales o solamente la de grado "1", cada entidad se transforma por RETECAR 1, y se genera una nueva tabla correspondiente a la relación formada por los atributos identificadores de ambas tablas y los atributos de la relación.
• RETECAR 4: En una relación binaria "n : n", o cualquier relación "n-aria", cada entidad pasa a ser una tabla, por RETECAR 1, y adicionalmente se genera una tabla para representar la relación. Esta nueva tabla estará formada por las PK de las entidades y los atributos de la relación, siendo la PK la agregación de las PK de las dos entidades.
• RETECAR 5: En una relación jerárquica, se desestimará la entidad supertipo, transfiriendo todos los atributos de ésta a cada una de las entidades subtipo. Las relaciones que tenía la entidad supertipo pasarán a ser consideradas por cada entidad subtipo.
• RETECAR 6: Se desestimarán las entidades subtipo, transfiriéndose todos los atributos de éstas a la entidad supertipo, así como cada una de las relaciones que las entidades subtipo mantenían
• RETECAR 7: La relación jerárquica se transformará en tantas relaciones "1 : 1" como entidades subtipo estén presente.

Nota: De las tres últimas RETECAR (5, 6, y 7) solo se aplica una por cada relación jerárquica, dependiendo de lo que el analista vea conveniente.

Con esto termina la teoría. Es el momento de aplicar estos pasos a nuestro prototipo de modelo E - R:

Para realizar el proceso, primero aplicaré las dos PRETECAR, y después usaré las reglas para usar las RETECAR.

a) PRETECAR:

 - Cambiamos el atributo "Apellidos" por dos: "apellido1" y "apellido2" -> PRETECAR 2.

Hasta aquí va todo bien. El modelo está preparado para ser transformado. Pero antes una anotación: es muy usual juntar los atributos de apellido (al igual que de nombre) en uno solo, pues hay gente que tiene un apellido, hay gente que tiene dos... y lo mismo con los nombres.

Yo soy partidario de separarlos siempre que sea posible (es decir, que no resulte "molesto"). En este caso irá bien separarlos, pero cuando pidamos los datos tendremos que tener en cuenta que deberemos pedir los apellidos por separado.

Ahora que está todo preparado, aplicamos a ambas entidades la RETECAR 1, quedando así:

usuario(nick, nombre, apellido1, apellido2, email, password)

estadistica(gana, tiempo, dificultad, opcion, autenticacion, minas, clicks, id_estadistica)

En la entrada anterior dejamos ver que la relación era "1 : n", por lo que tenemos que aplicar la RETECAR 3. Del mismo modo, y como hay un atributo de relación (aunque no lo especifiqué), procederemos a usar la RETECAR 3.2.

Entonces, quedaría así:

usuario(nick, nombre, apellido1, apellido2, email, password)
estadistica(gana, tiempo, dificultad, opcion, autenticacion, minas, clicks, id_estadistica)
juego(nick, id_estadistica, fecha)

Leyenda:

• Negrita y cursiva: nombre tabla
• Subrayado: clave primaria (PK)
• Cursiva: clave foránea (FK)
• Negrita y subrayado: clave primaria y clave foránea (PK/FK)

Finalmente, hacer un par de anotaciones: he añadido un atributo (id_estadistica) para poder distinguir todos los registros entre ellos. También, como he dicho antes, olvidé mencionar la fecha, pero es algo que no es obligatorio; sin embargo da mucho más juego y utilidad tenerlo.

Bien, de momento tenemos el modelo relacional. En la próxima entrega lo normalizaremos. Aunque vamos a intentar normalizarlo hasta la quinta forma normal (5FN), lo normal es hacerlo hasta la forma normal de Boyce-Codd (FNBC).

Y, con esta reflexión, os dejo.

¡Hasta la próxima!

A buscar M!nas: MSAccess - Modelo E-R

Buenas de nuevo!

En esta entrada trataremos el modelo entidad - relación (E - R) en base a los requerimientos expuestos en la entrada anterior.

De los datos marcados, podemos ver como hay dos tablas: por una parte tenemos los usuarios, y por otra, las estadísticas.

De la primera tabla guardaremos:

• Nick
• Nombre
• Apellidos
• Email
• Password

De la segunda:

• Si ha ganado
• Tiempo
• Dificultad
• Clicks
• Minas marcadas
• Autenticación
• Opción

Leyendo el texto, también podemos deducir la relación; un usuario tiene un registro único de estadísticas, y un registro de estadísticas corresponde a un usuario (si es un usuario anónimo, ese usuarios puede ser varios a la vez).

¿Ésto cómo se traduce? Bien, a nivel de base de datos, un registro de estadísticas estará compuesto por varias entradas. Por tanto, deducimos que la relación será 1 : *

He creado un pequeño esquema de las dos tablas y la relación que tienen. Os lo adjunto:

Modelo E - R

De momento esto es todo para esta entrega.

En la próxima empezaremos con la teoría del modelo relacional. Haremos todo el proceso en una entrega, de manera que así me veré forzado a no extenderme demasiado con la teoría (en realidad es bastante rápido, incluso automático cuando te lo aprendes).

Hasta la próxima!

A buscar M!nas: MSAccess - Requerimientos

Buenas!

Empezamos ya con la primera mejora para nuestro juego de M!nas. Esta mejora servirá como base para las próximas mejoras.

Tal como indiqué en la entrada anterior (en el índice), en esta entrada redactaré de forma textual los requerimientos de nuestra aplicación.

Para ello describiré la "aplicación ideal". Posteriormente extraeremos la información útil y la adaptaremos a un modelo E-R adaptado a un modelo local..

Empecemos, pues:

La idea es tener una aplicación con un sistema de base de datos.

La aplicación (el juego de las M!nas) enviará información diversa para registrarla.

Así, una ejecución normal del juego consistiría en:

• Se abre el ejecutable
• Un pop-up pide un modo de autenticación:
• Usuario y password
• Anónimo
• Crear cuenta
• Una vez entrado el modo de autenticación, se pide la dificultad y la opción.
• Se carga el juego
• Al finalizar el juego se envían estadísticas. Esto es
• Si ha ganado o perdido
• Tiempo transcurrido
• Dificultad
• Opción
• Usuario jugado
• Modo de autenticación
• Minas marcadas
• Número de clicks

Cada usuario será único. En caso de que el usuario sea anónimo, significa que no está registrado, y por tanto puede ser cualquiera (es decir, dos personas diferentes pueden usar los mismos datos).

De este modo, un usuario registrado tendrá un registro único de estadísticas, mientras que un usuario anónimo puede tener varios registros, estando en el mismo registro físico.

Para registrar un usuario hace falta un nick, un nombre, apellidos, correo electrónico y un password. Para un usuario anónimo se pedirá un nick.

Esta es la especificación de requerimientos, en un modo textual. De este texto se puede extraer toda la información necesaria para crear la base de datos. Toda la información ha sido destacada de la siguiente manera:

Los nombres de tablas están en azul y negrita
Los nombres de campos están en verde y negrita

Se puede apreciar a simple vista que el futuro modelo Entidad - Relación será pequeño. Pero esto no quiere decir que se pueda hacer a la ligera.

Tenemos que proceder siempre con cautela y cuidado, para intentar cometer siempre el mínimo número de errores.

Estas medidas pueden parecer inútiles y contraproducentes, pero es todo lo contrario; es preferible estar seis u ocho horas analizando un problema y luego dos horas programando que empezar a programar y luego parchear todo a base de debug. Además, el analizar las cosas nos proporciona una vista más amplia del problema y nos permite subdividirlo de manera que las funciones y clases que hagamos serán realmente útiles.

Después de esta pequeña reflexión, voy a preparar la siguiente entrada. De momento lo dejamos aquí.

¡Hasta la próxima!