viernes, 18 de diciembre de 2020

Bases de Datos(18/12/2020)

 Continuación Unidad 3

En la clase online de hoy hemos continuado con el contenido de la unidad 3 de Bases de Datos, el Modelo Relacional. En particular, hemos seguido realizando ejercicios sobre la obtención del modelo relacional de una serie de esquemas E/R( Entidad/Relación). Se han realizado los ejercicios 1, 2 y 3 de los propuestos en el aula virtual, el resto se ha propuesto ir haciéndolos para tratarlos en la próxima clase. 

jueves, 17 de diciembre de 2020

Lenguaje de Marcas(17/12/2020)

 Continuación Selectores

En la clase hemos continuado viendo los selectores, como los selectores de id. Hay que aplicar un id, con el nombre que queramos, en la etiqueta que queramos aplicar unas características concretas y únicas en esa etiqueta. El nombre que apliquemos a un id no se puede volver a usar en ese documento. Se ubica justo después del nombre de la etiqueta, ejemplo: <h1 id="encabezado">. En CSS, los id se representan con el símbolo "#".

Se ha visto los modelos de cajas en CSS. Una caja es donde se encuentran un conjunto de elementos, o solo un elemento (muchos elementos forman una caja propia automáticamente) que queremos acotar, por tener relación entre ellos en nuestra página o por otro motivo en un documento de HTML. En los estilos de CSS, se pueden aplicar una serie de características a las cajas. Algunos son: border, margin, float, padding, etc.

Se ha observado que es muy importante validar nuestra página web, además de realizar una serie de pruebas en distintos navegadores de internet para comprobar que nuestra página funciona. Se puede comprobar mediante unas webs concretas, lo que los navegadores son capaces de soportar o no, como por ejemplo caniuse.com

lunes, 14 de diciembre de 2020

Bases de Datos (14/12/2020)

 Continuación Modelo Relacional

En la clase de hoy se ha continuado con el concepto del Modelo Relacional y las tablas. Se ha hecho una comparativa entre un diagrama de un modelo de Entidad/Relación (Como el que hemos hecho en el proyecto de BBDD de la 1º Evaluación) y como quedaría en un sistema gestor de bases de datos (SGBD), en forma de tablas, columnas, etc.

En cuanto a las entidades relacionadas con las tablas, se conservan los atributos y la clave principal (Primary Key (PK)) por ejemplo: entidad= asignatura, atributos= CodAsig, Nombre, Créditos, Carácter, curso.

Las Claves Candidatas se establece una restricción de unicidad. Los atributos compuestos se indican en un campo por atributo, los atributos derivados se indican en columnas calculadas, los atributos multivaluados se indican en una nueva tabla. Si hubiese restricciones sobre atributos, se indica en lenguaje lógico.

En una tabla, las entidades débiles conservan sus atributos y se le añade la clave principal de la entidad fuerte de la que depende. Siendo la relación de identificación, la clave principal la forma un atributo de la entidad débil y la clave principal de la fuerte. Si fuese de existencia, tendrá su clave propia, pero se establece borrado y en actualización en cascada con respecto a la entidad fuerte. ejemplo: entidad=Grupo, atributos=(CodAsig, CodGrupo, max_alum).

En cuanto a las relaciones en una tabla, están formadas por los atributos de las claves principales de las entidades conectadas y los de las relaciones. la  clave principal depende de la cardinalidad de la relación. en una cardinalidad M:N, su clave principal está formada por las claves principales de la entidades relacionadas, como mínimo. Tiene una dimensión temporal. Ejemplo: relación=Consta, Clave principal=CodMatr, CodAsig, CodGrupo, Convocatoria, calificación.

En una cardinalidad 1:N, su clave principal estará formada por la clave principal de la entidad con la cardinalidad N. Ejemplo: relación=Pertenece, clave principal=CodProf, CodDpto.

La cardinalidad 1:1, su clave principal estará formada por una clave principal de una de las entidades, la otra entidad actuará como clave candidata. Ejemplo: relación=Dirige, clave principal=CodProf, CodDpto.

Cuando surgen demasiadas tablas en estos casos, se pueden hacer reducciones de tablas. Solo se pueden reducir tablas en los casos de cardinalidades 1:1 y 1:N.

En casos en los que haya relaciones reflexivas, hay dos opciones: que se generen dos tablas con una clave principal de la entidad, con sus atributos, y otra con la clave principal de la relación con los atributos. Otra forma sería crear una tabla con una clave ajena.

Generalizando, al final se debe crear una tabla por cada entidad que participa. También se puede crear una tabla para cada caso particular, eliminando la super-entidad y añadiendo atributos de la super-entidad a las otras entidades. Este caso es menos frecuente. Hay otra manera de hacerlo que seria creando una tabla  con una sola relación, que tomaría atributos de las entidades, pero este caso es también poco utilizado.

Existen unas restricciones semánticas de Totalidad/Parcialidad o de Exclusividad/Solapamiento. Las de totalidad/parcialidad se controla la totalidad prohibiendo la inserción en el supertipo directamente, primero se inserta en los subtipos (disparadores). la parcialidad no requiere disparadores.

Las de exclusividad/solapamiento, se requiere un aserto (Trigger) que comprueba que si un ejemplar esta en un subtipo, no puede estar en otro.

En relaciones N-Arias, una relación puede tener varias interpretaciones y todas ellas válidas. Dependen de la cardinalidad: si es N:M:S, su PK(Primary Key) es el conjunto de las PK de cada relación. Si es N:M:1, la PK será el conjunto de las PK con una cardinalidad distinta a 1. Si es N:1:1, es posible que se divida en dos relaciones 1:n.

Al final de la clase se ha dedicado a realizar algún ejercicio de ejemplo sobre lo visto hasta ahora, sobre los modelos relacionales y el paso a tablas. 




viernes, 11 de diciembre de 2020

Bases de Datos (11/12/2020)

 Continuación Unidad 3

En la clase de hoy hemos continuado con el tema 3, sobre el modelo relacional, haciendo un breve repaso de lo visto en la última clase y comenzando con la arquitectura de ANSI-SPARC y los gestores relacionales

Se ha visto las diferencias entre el Modelo Relacional (MR) y el ANSI. Aunque el MR se adapta a ANSI, hay algunas excepciones como: 

En MR se permite a un usuario acceder a las relaciones base y las vistas si tiene las autorizaciones. En ANSI el usuario está restringido a la parte externa de la base de datos. En MR no se pueden actualizar todas las vistas, al contrario que en ANSI. Muchas SGBD relacionales no responden a la arquitectura a tres niveles.

A continuación se ha hecho un repaso de como acceder a la máquina virtual, con el servidor debian, a la vez que accedíamos al sistema gestor de bases de datos, en nuestro caso HeidiSQL. A través de este SGBD, donde habíamos creado una base de datos, hemos creado a modo de ejemplo una columna con alguna fila con datos. También se ha repasado de forma similar con otro SGBD que se utilizará, MySQL Workbench.

Después se ha visto las 12 reglas de Codd:

Regla genérica: Un SGBD relacional debe emplear sus facilidades relacionales para gestionar la base de datos. de aquí surgen las 12 reglas:

  1. Representación de la información: toda información es representada de forma explícita y única a nivel lógico, con valores en tablas, columnas y filas.
  2. Acceso garantizado: todo dato debe ser accesible mediante una combinación de tabla, valor de su clave y nombre de columna.
  3. Tratamiento sistemático de valores nulos: debe soportar la representación y manipulación de información desconocida y/o no aplicable.
  4. Catálogo en línea: la descripción se debe representar en el nivel lógico, igual que los ordinarios, para los usuarios autorizados.
  5. Sublenguaje de datos completos: debe soportar al menos un lenguaje relacional (con sintaxis lineal, usado interactivamente o embebido y con soporte para operaciones de tipo manipulación de datos, definición de datos, etc.).
  6. Actualización de vistas: vistas actualizables deben serlo en la práctica.
  7. Inserción, modificación y borrado de tuplas de alto nivel: operaciones de manipulación de datos operan sobre conjuntos de filas.
  8. Independencia física de los datos: cambios en el acceso físico o almacenamiento no debe afectar al acceso lógico.
  9. Independencia lógica de los datos: programas de aplicación no deben ser afectados por cambios en tablas que preservan la integridad.
  10. Independencia de la integridad: deben estar separadas de los programas, almacenados en el catálogo de la BD para su edición.
  11. Independencia de la distribución: las aplicaciones no deben estar afectadas al distribuir o cambiar la distribución de la Base de Datos.
  12. Reglas de no subversión: si es interfaz de bajo nivel, no puede usarse para saltarse las reglas de integridad y las restricciones expresadas por un lenguaje de nivel superior.
Se ha visto las fases de diseño de una base de datos: análisis de requisitos, diseño conceptual, diseño lógico y diseño físico, carga de datos y pruebas y operación.

Están clasificados los modelos de datos entre conceptuales y lógicos.

Por último, se ha tratado las herramientas tipo CASE. Estas ayudan al programador o analista en el diseño conceptual para pasar al lógico o físico, ejemplos como Visio, Oracle designer, EasyCase, etc. Estas herramientas permiten el diseño del modelo de datos conceptual siguiendo las anteriores técnicas, normalmente ER o UML, para obtener el esquema lógico relacional, escrito en SQL estándar o físico. Las herramientas CASE ayudan al diseño, reducen el tiempo de desarrollo, mantenimiento del esquema de datos, reducen el tiempo de la documentación y facilitan la portabilidad a otros gestores.

Bases de Datos (09/12/2020)

Continuación Unidad 3, Modelo Relacional

En la clase de hoy hemos continuado con los modelos relacionales, en particular se ha estado repasando las restricciones semánticas vistas en la clase anterior y, en esta clase, hemos visto otras restricciones no vistas anteriormente como: el Foreign key (Claves Ajenas), que consiste en la integridad referencial. 

Dentro de la Foreign Key, se encuentran acciones como: No Action, Cascade, Set Null y Set Default.

Ejemplo de Clave Ajena:


A continuación vimos el Check (Comprobación), comprueba que el dato introducido se encuentra dentro del Check, si no esta dentro del campo del Check lo rechaza y no entra. 

Ejemplo en un único elemento: Check (porcentaje >0 and porcentaje<100).

Ejemplo en nivel relación: Check (fecha_fin >= fecha_ini). 

Está el Assertion (igual que el Check, excepto que esta puede afectar a varios elementos o relaciones distintas), debe tener siempre un nombre debido a que no va unida a un elemento determinado.

Ejemplo: empleados que participan en una misma tarea, perteneciendo al mismo departamento que el responsable.

Los Valores Nulos se utilizan para representar información que se desconoce, es inexistente, no es valida, es indefinida, etc.

Por ejemplo: crear tuplas con atributos con valor desconocido en ese momento, pero que en algún momento se conocerá. Añadir un nuevo atributo a una relación existente, sin valor en ese momento. Atributos inaplicables a ciertas tuplas (ejemplo: la editorial para un artículo (los artículos no tienen editorial)).

El valor nulo necesitará, en ocasiones, introducir operadores especiales como Is Null o Maybe.

La clase termina empezando a ver un punto importante, el Esquema de una Relación

R <A:D, S>

R: nombre de la relación.

A: lista de atributos.

D: dominios sobre los que están definidos los atributos (afectan a las tuplas y/o atributos).

S: restricciones de integridad intraelementos (afectan a los atributos y/o tuplas de una relación).

También el Esquema de una base de datos relacional.

E< {RI}, {li} >

E: nombre del esquema relacional.

{RI}: conjunto de esquemas de relación.

{li}: conjunto de restricciones de integridad interelementos ( afectan a más de una relación o dominio).




jueves, 10 de diciembre de 2020

Lenguaje de Marcas (10/12/2020)

En la clase de hoy se ha fijado, para los que lo tengan que hacer, el examen de recuperación de Lenguaje de Marcas, además de empezar a dar las clases por videoconferencia para los que no tengan o no puedan venir a clase, tanto de Lenguaje de Marcas como de Bases de Datos.

Continuación Unidad 2.2

Hemos continuado con la parte de CSS en una hoja de estilos para una página web. Al principio se ha dado un repaso a los contenidos vistos con anterioridad y, después, hemos empezado a ver la parte de los selectores. la función de los selectores es identificar en la parte HTML elementos concretos a los que le queramos proporcionar ciertos estilos o características en CSS. Encontramos selectores más importantes, que son los utilizados normalmente en las páginas web como: selectores universales (*), de tipo etiqueta (h1, p, body, etc), descendentes (h1 p a, p * a, etc) de clase(class) y de id (id). 

Aparte se encuentran los selectores hijo (p > a), incluyéndose el nieto (p * a), que consiste en que, dentro un elemento compuesto por varias etiquetas, se selecciona únicamente la etiqueta (hijo) que sigue a la principal (padre) para proporcionarla estilos o atributos. Si se quisiera usar la siguiente etiqueta a la hijo, pero sin que afecte al propio hijo, sería la etiqueta nieto, utilizando el selector universal (*) en vez del hijo(>). los selectores hermanos son los elementos que van uno a continuación del otro pero sin relación entre ellos, aplicándoles los mismos estilos o atributos, por ejemplo: h2 + h3{ color: blue}.

Los selectores atributos, básicamente, se utilizan cuando se quiere aplicar algún estilo a elementos que tengan los mismos atributos. Se encuentran 4 tipos de selectores atributo: [atributo] selecciona los elementos con el mismo atributo, [atributo=valor] selecciona elementos con el mismo valor del atributo, [atributo ~= valor]selecciona los elementos que tengan al menos el atributo especificado, [atributo |= valor]Selecciona elementos con el atributo y que comience por el valor especificado.

Los selectores tipo class proporcionan estilos a uno o diferentes elementos que contengan el mismo tipo de clase. para identificar los class se utiliza en la hoja de estilos de CSS un punto (.) + el nombre del class.

Los selectores id proporcionan estilos a elementos concretos. Se identifican con un id + nombre del id en HTML y, en CSS, se representa con una (#). Cuando se usa un id no se puede repetir en otro elemento ese mismo identificador con el mismo nombre, cada elemento se le proporciona un id con un nombre distinto de identificador.

La clase ha terminado practicando un poco en VSC utilizando los selectores aprendidos.


miércoles, 9 de diciembre de 2020

Bases de Datos(04/12/2020)

 Comienzo Unidad 3

En la clase de hoy hemos comenzado a tratar la unidad 3 del temario de Bases de Datos. Esta unidad consiste en el paso del modelo Entidad/Relación al modelo Relacional. El tema 3 comienza hablando sobre el modelo Lógico, ubicado en la fase 2 de la creación de una base de datos. 

martes, 1 de diciembre de 2020

Lenguaje de Marcas (01/12/2020)

 Continuación CSS

En la clase de una hora de hoy hemos continuado con la parte de estilo CSS en una página web. Se ha recordado que el mejor método de aplicación de CSS es mediante la creación de una hoja de estilos aparte, enlazándolo con el HTML mediante la etiqueta <link>. Se ha visto la etiqueta <meta>, para especificar el tipo de lenguaje de estilos que vamos a usar. Colocándola en la parte <head> del HTML.

ej-<meta http-equiv="Content-Style-Type" content="text/css">

Se ha practicado mediante la creación de una página, aplicándole tanto un pequeño contenido de HTML donde se incluye una tabla básica, como estilos CSS.


Entrada de Bienvenida al Blog