NORMALIZACION

Diseño y normalización de bases de datos relacionales 

Diseñando la BD

Para diseñar una base de datos se parte de la recolección de atributos o campos que va a tener, y de la definición de sus tipos de dato. La manera más profesional es realizando el análisis de requisitos con todas las personas que van a hacer uso de los datos. Pero por experiencia ya sabéis que esto se hace muy a ojo: os piden realizar una aplicación y según los requisitos de la aplicación hacéis el diseño de la BD.

El primer método está más estandarizado, y suele ser más lento pero a cambio es improbable que el diseño salga mal. El segundo es más rápido porque directamente se piensa en las tablas y sus datos sobre la marcha. Se utiliza principalmente en la metodología de programación conocida como “programación extrema” y en las demás de la familia “desarrollo ágil de software”; y es más propenso a fallos de diseño, proporcionalmente inversos al tiempo que se dedique a su definición y valoración (más tiempo, menos probabilidad de fallos).

Normalizando la BD

La normalización es un método de análisis de BD para conseguir una BD relacional, que respete la integridad referencial, y que no tenga redundancia de datos. Se divide en formas normales, y aunque hay un montón y es toda una ciencia, explicaré por encima las 3 primeras ya que el nivel 3 es suficiente para la mayoría de casos.

Hay que destacar que la normalización se puede hacer a nivel completo de la BD, o a nivel de tablas o esquemas. La técnica es la misma: analizar el conjunto de campos y en base a eso designar una clave inicial que identifique a un grupo de datos. Por ejemplo si estamos normalizando todo un esquema de facturación podemos partir de los datos del cliente añadiendo la clave del cliente, y según vayamos normalizando nos saldrán todas las tablas y les iremos dando claves primarias nuevas. Si lo que normalizamos es una tabla, el procedimiento es el mismo y ya irán saliendo otras tablas subordinadas si acaso.

Las reglas de Codd

Además de la normalización hay unas reglas, las reglas de Codd, que ayudan a diseñar una BD relacional perfecta (desde el punto de vista de Codd, claro) que merece la pena estudiarlas pues son casi de lógica común y nos harán la vida más fácil en todos los sentidos. La idea de estas reglas surgió porque la normalización no era suficiente para que una BD fuera relacional, consistente e independiente.

Hay ocasiones en las que los diseñadores de las BD confeccionan la BD para satisfacer necesidades lógicas y funcionales de una aplicación, por ejemplo almacenando los datos en un formato que luego la aplicación se encarga de transformar. Esto es bastante típico cuando el diseñador es el programador de la aplicación, y lo hace por comodidad o falta de conocimiento.

La moraleja es que una BD debe ser independiente de la aplicación, y si lo pensáis bien es mejor así. Según las reglas de Codd la BD tiene que ser completamente operativa desde su lenguaje de consultas (típicamente SQL), y las restricciones en los datos deben ser propiedad de la BD (no vale controlar la entrada desde la aplicación). Con esto conseguiremos que mediante el SQL no se puedan realizar operaciones que hagan que la aplicación no funcione (introduciendo datos en un formato inesperado para la aplicación, por ejemplo), y entre otras cosas, que si tenemos que realizar informes puntuales o sacar listados los podremos hacer desde un simple cliente y sin tener que parsear nada ni realizar consultas sobre consultas.

Normalizando la BD: primera forma normal (1FN)

Se podría decir que al aplicarla hay que asegurarse de que:

• No se permiten vectores de campos en una columnaUn ejemplo de esto es cuando en un campo de texto metemos varios valores del mismo dominio,
  como por ejemplo tres números de teléfono, o dos direcciones e-mail. Lo típico en estos casos
  es separar los datos por comas, espacios u otro carácter y depués procesarlo mediante la aplicación.
  Para evitar esto hay que definir una nueva tabla que tendrá el identificador de la tabla de la que parte y
  el campo multivaluado, haciendo juntos de clave única compuesta (se puede definir otra incremental si se desea,
  pero el conjunto de los otros dos campos tiene que ser único). Además en esta tabla se puede agregar campos
  que ayuden a describir el tipo de registro.

Ejemplo

Incorrecto

clientes

IDCliente	Nombre	Telefono
45	Francisco	444444444
275	Miguel	555555555,666666666

Correcto

clientes

IDCliente	Nombre
45	Francisco
275	Miguel

telefonos_cliente

IDCliente	Telefono
45	444444444
275	555555555
275	666666666

• No se permiten grupos repetidos en varias columnas
  Esto es una variante de lo anterior: separamos los campos de un mismo dominio en varias columnas, haciendo un grupo difícilmente procesable a la hora de consultarlo. En el ejemplo anterior sería tener el campo telefono1, telefono2… y así. Es evidente que este fallo del diseño es incluso peor que el anterior pues habrá muchos campos nulos, y en caso de necesitar más tendríamos que redimensionar la tabla con un nuevo campo (telefono3). Pero la solución es sencilla: la misma que en el anterior caso.

Ejemplo

Incorrecto

clientes

IDCliente	Nombre	Telefono	Telefono2	Telefono3
45	Francisco	444444444	NULL	NULL
275	Miguel	555555555	666666666	NULL

Correcto

clientes

IDCliente	Nombre
45	Francisco
275	Miguel

telefonos_cliente

IDCliente	Telefono
45	444444444
275	555555555
275	666666666

• No se permiten campos nulos
  Esta regla es algo discutible, pero tiene su lógica. Para empezar, si un campo va a tener valores nulos, ¿qué proporción de registros tendrán ese campo con valor nulo? En mi opinión esta regla nos ayuda a separar
  unas entidades de otras, porque si una cantidad de registros tienen unos atributos que otros no, ¿no será que pertenecen a otra clase? Por ejemplo, si en una tabla de productos definimos los campos talla, kilates y potencia se ve que los productos tendrán clases diversas y entonces habrá que crear una entidad para cada clase (ropas, joya y eléctricos, por ejemplo) construyendo lo que se llama una generalización.

Ejemplo

Incorrecto

productos

IDProducto	Nombre	Talla	Kilates	Potencia
147	Blusa fashion	44	NULL	NULL
155	Broche duquesa	NULL	24	NULL
221	Subwoofer extreme	NULL	NULL	1500

Correcto

productos

IDProducto	Nombre
147	Blusa fashion
155	Broche duquesa
221	Subwoofer extreme

ropas

IDProducto	Talla
147	44

joyas

IDProducto	Kilates
155	24

electricos

IDProducto	Potencia
221	1500

Normalizando la BD: segunda forma normal (2FN)

Una tabla está en segunda forma normal siempre que esté en primera forma normal y todos sus atributos (campos) dependan totalmente de la clave candidate sin ser parte de ella. Viene a ser que, si un campo de la tabla no depende totalmente de una clave única (que pueden ser compuestas), debe sacarse fuera con la parte de la clave principal de la que es dependiente.

Ejemplo

Incorrecto

lineas_pedido

IDCliente	IDProducto	Cantidad	Nombre_producto
29	42	1	Zapatillas deportivas de tenis
46	9	5	Balón reglamentario de baloncesto
204	42	1	Zapatillas deportivas de tenis
144	10	1	Zapatillas deportivas de rugby

Correcto

lineas_pedido

IDCliente	IDProducto	Cantidad
29	42	1
46	9	5
204	42	1
144	10	1

productos

IDProducto	Nombre_producto
9	Balón reglamentario de baloncesto
10	Zapatillas deportivas de rugby
42	Zapatillas deportivas de tenis

Como vemos en la tabla “lineas_pedido” del ejemplo incorrecto, la única clave candidata es IDCliente + IDProducto, ya que en conjunto son únicas en la tabla (podríamos tener un IDLinea_pedido único también, pero aún así esos dos campos segurían siendo una clave candidata). El campo Cantidad es dependiente de la clave candidata, pues el cliente ha pedido de ese producto una cantidad determinada de artículos, pero el nombre en cambio es dependiente sólo del producto, no del cliente. Si dejaramos esa tabla como está, tendríamos por una parte una redundancia de datos innecesaria pues el nombre del producto lo podemos sacar uniendo la tabla de productos, y además podrían darse inconsistencias de datos si cambiamos el nombre del producto en un registro… ¿cuál sería el nombre real del producto 42 si en varios registros tiene un nombre distinto?

Conclusiones

Por lo tanto los pasos para aplicar la segunda forma normal son muy sencillos: encontrar las claves candidatas (compuestas), que identifican de manera única el registro; comprobar que los campos que no forman parte de la clave candidata y no son parte de ella (en el ejemplo de antes ni IDCliente ni IDProducto deben ser analizados) dependen totalmente de la clave candidata. Para el segundo paso puede ayudar preguntarse lo siguiente:

¿puedo saber el valor del campo X sabiendo el valor del campo Y (siendo Y parte de la clave candidata y X no siendo parte de ella)? Pero como todo lo relacionado con el análisis esto requiere un mínimo de agudeza, pues puede que casualmente el valor de un campo se repita para una parte de la clave (por casualidad todos los que compran unas pelotas de tenis lo hacen en cantidades de 5) pero sabemos que no es dependiente de ella.

Por último, aclarar que hay ocasiones en las que el análisis no tiene que ser tan cerrado, ya que a veces las apariencias engañan. Un ejemplo de ello es una tabla de facturas que tiene el nombre, dirección, NIF, y demás datos del cliente: a simple vista esos datos están duplicados y dependen del cliente y no de la factura, pero resulta que esos datos deben permanecer ahí pues fiscalmente debemos saber a qué datos se emitió una factura; esos datos son realmente dependientes de la factura, no del cliente. Si no los incluyéramos en la tabla de facturas, al modificar el registro del cliente en la tabla de clientes no sabríamos a qué datos fiscales se emitió la factura. Así que una vez más, hay que utilizar un poco de ingenio y no aplicar normas como una máquina y sin pensar.

Normalizando la BD: tercera forma normal (3FN)

Una tabla está en tercera forma normal siempre que esté en segunda forma normal (y por consiguiente en primera) y todos sus campos no primarios (campos que no forman parte de una clave candidata) dependen únicamente de la clave candidata. Suena como la segunda forma normal, pero es muy distinta: ningún campo que no sea parte de la clave candidata puede depender

de otro campo que no sea la clave candidata.

Ejemplo

Incorrecto

carga_diaria

IDServidor	Fecha	IDServicio	Nombre_servicio	Carga
21	2009-01-14	1	Oracle	100
21	2009-01-15	9	MySQL	100
21	2009-01-16	22	Apache	85
34	2009-01-14	3	PostgreSQL	74
34	2009-01-15	22	Apache	58
34	2009-01-16	22	Apache	67
66	2009-01-14	9	MySQL	98
66	2009-01-15	22	Apache	94
66	2009-01-16	1	Oracle 10g	84

Correcto

carga_diaria

IDServidor	Fecha	IDServicio	Carga
21	2009-01-14	1	100
21	2009-01-15	9	100
21	2009-01-16	22	85
34	2009-01-14	3	74
34	2009-01-15	22	58
34	2009-01-16	22	67
66	2009-01-14	9	98
66	2009-01-15	22	94
66	2009-01-16	1	84

servicios

IDServicio	Nombre_servicio
1	Oracle
9	MySQL
22	Apache
3	PostgreSQL
22	Apache
22	Apache
9	MySQL
22	Apache
1	Oracle 10g

Imaginad que una tabla se encarga de registrar el primer servicio que más carga los servidores cada día. Del ejemplo incorrecto deducimos que el IDServidor y la Fecha son la clave candidata, pues identifican de manera única los registros. Analizando vemos que el IDServicio, que no es un campo primario, depende únicamente de la clave candidata, y que la carga también. Pero resulta que el Nombre_servicio depende de esa clave candidata pero también depende del IDServicio, pues con el IDServicio podemos averiguar qué Nombre_servicio tiene el registro. Para solucionar esto sacamos el campo Nombre_servicio de la tabla, y nos llevamos el IDServicio para que sea la clave principal pues es el campo del que depende.

Y con este ejemplo vemos qué fácil es librarnos de las inconsistencias de no cumplir la tercera forma normal, y de la redundancia de datos. Si no hubieramos normalizado tendríamos que en un registro el IDServicio 22 es Apache y nadie nos asegura que en otro el IDServicio 22 también lo sea pues puede haberse modificado el campo Nombre_servicio. Y si resulta que la tabla fuese un histórico de 500 servidores durante 1000 días, tendríamos 500 mil registros con un campo innecesario que estaría duplicado muchísimas veces.

Diseñando la BD sobre la marcha

Si en vuestro desempeño habitual del trabajo os encontráis con que no podéis aplicar, de una manera formal y detallada, la normalización a la hora de diseñar BD, no os alarméis pues le pasa a mucha gente. Lo que puede ocurrir es que nos quede una BD no relacional, y eso es siempre negativo, pero a base de experiencia iréis adquiriendo una soltura y capacidad analítica automáticas.

La normalización, al basarse en reglas lógicas, se puede memorizar muy fácilmente y al final forma parte del instinto del diseñador: no necesitaréis bolígrafo y papel para ver que una tabla no está normalizada. De hecho cuando sepáis que datos necesita la aplicación pensaréis directamente en las tablas que saldrán.

Primero, documentarse

Lo más importante para diseñar la BD sobre la marcha es tener la mente amplia, conocer las bases de la normalización, y dejarse aconsejar por los expertos. Todo esto de las BD relacionales no es nuevo y hay muchos gurús (Codd, Edgar Frank Codd, es el padre de todos) que os pueden ayudar a entender qué características debe cumplir una BD para ser relacional. De modo que si no sabéis del tema, lo mejor es que os olvidéis de las malas enseñanazas que tengáis imbuidas: una BD con muchas tablas no está mal diseñada (una con pocas es más probable que sí lo esté); llevarse el código del cliente a todas las tablas (lo necesiten o no) no es la forma de tener una BD relacional; guardar los datos serializados en un campo no te hace la vida más fácil; tener un campo que hace referencia a una tabla unas veces y a otra en otras ocasiones no es un buen diseño (un campo referencial sólo puede referenciar a una tabla, así que usad la generalización en esas situaciones).

Errores habituales

Un error habitual a la hora de usar este método de diseño es tener un campo referencial que admite valores nulos o vacíos (típico clave_referencia 0 cuando no referencia a nada). Si la BD es relacional, un campo referencial tiene que apuntar a otro registro en la BD. A veces tenemos un campo IDPadre que hace referencia a un mismo registro de la tabla, o vale 0 cuando el registro es padre en sí… pero lo correcto en una relación reflexiva (una tabla relacionada consigo misma) que da lugar a otro tabla que contiene el IDHijo y el IDPadre; consultando esa tabla podemos saber si un registro es hijo (tiene entradas con su ID en IDHijo) o padre (su ID está en algún IDPadre) y sacar todos los hijos de un padre.

Consejos

Otro buen consejo, que no está limitado a este método de diseñar, es tener en cuenta el tamaño de las tablas en cuanto a longitud de fila (en bytes). De hecho recuerdo que me hablaron de una regla de diseño de BD que decía que una tabla no debía contener más de X campos… y bueno, siempre es discutible pero es más óptimo que la longitud de la fila no sea muy larga, sobre todo en las tablas que se consultan con frecuencia. Es una práctica muy recomendada que si tenemos campos grandes, tipo TEXT o BLOB, saquemos esos datos a otra tabla para que las búsquedas y JOIN generales que no necesiten ese campo sean más rápidas. Hay que tener en cuenta que el sistema de gestión de BD (SGBD) en ocasiones no puede optimizar las consultas y necesita escanear por completo la tabla, o tiene que volcarla a la memoria física o virtual.

En definitiva: recordad que una BD relacional no puede ser dependiente de la aplicación, sino al revés. Así que olvidaros de diseñarla pensando qué es lo mejor para la aplicación, y pensad qué es lo correcto para que sea más óptima y sencilla de manejar independientemente del cliente que la maneje (aplicación, consultas directas, herramientas de informe…).

En Recepcion

TotalImporte

IGV

TotalBruto

Descuento

TotalNeto

En Deta_recep Importe

EJERCICIOS DE DIAGRAMA ENTIDAD RELACION

Ejercicio 1. Se desea modelar parte de la realidad de la oficina de trabajo de una Facultad. La oficina de trabajo recibe ofertas de empleo y cada vez que esto ocurre se abre un llamado a estudiantes interesados. A cada llamado se le asigna un número, una descripción, la fecha de aparición y la fecha límite de presentación al mismo. Los llamados pueden ser para una empresa o para una facultad. Si el llamado es para una empresa se sabe el nombre de la misma y si desea figurar o no en el aviso que saldrá publicado. Cuando la oferta de empleo proviene de una facultad, se conoce el nombre de la institución y dentro de la misma qué instituto u oficina realizó la solicitud. Para anotarse a un llamado, el estudiante debe estar registrado en la oficina. De los estudiantes se conoce su cédula, nombre, fecha de nacimiento, dirección, email, currículum y teléfonos. Además se sabe en que carrera de las que dicta la Facultad están más avanzados. Se considera una sola carrera por estudiante. De cada estudiante inscripto al llamado se registra la fecha de inscripción al mismo. Los currículum de los estudiantes presentados se envían a la empresa o facultad que ofrece el empleo, para que esta realice la selección. En caso que la empresa decida no contratar a nadie el llamado se declara como desierto y se registra el motivo de tal situación para tenerlo en cuenta en futuros llamados. También puede suceder que ningún estudiante se inscriba para un llamado, en cuyo caso el llamado también será declarado como desierto. De lo contrario se registran los estudiantes contratados en el mismo. Diseñar un MER que represente la información de los llamados y sus posibles resultados. Ejercicio 9. Una empresa de entretenimientos y vacaciones para niños en edad escolar y preescolar desea automatizar el manejo de la información de sus clientes y las asociaciones con las que trabaja. La información que se desea mantener tiene las siguientes características: Existen varias asociaciones juveniles, las cuales tienen sus propias colonias de vacaciones. Cada asociación tiene varias colonias, pero cada colonia pertenece a una única asociación. De cada asociación se conoce su nombre, que la identifica, la dirección y un teléfono de referencia. De las colonias se conoce su código y ubicación; el código puede repetirse para las distintas asociaciones. En las colonias trabajan varios líderes de grupos, de los cuales se conoce su C.I., nombre y teléfono. Cada líder puede trabajar para varias colonias. Todos los líderes deben tener una certificación que los acredita como tales, interesa la fecha, el grado y la asociación que emitió el certificado. En caso de tener más de un certificado interesa sólo el más reciente. Curso BD y Sistemas de Información Practico 1 – Modelo Entidad Relación Instituto de Computación – Facultad de Ingeniería – Universidad de la República Página 6 de 8 Cada líder en una colonia coordina exactamente una actividad, pero puede ayudar en otras. Las actividades a su vez son desarrolladas (coordinación y ayuda) por varios líderes de colonias. De las actividades se conoce su identificador y una breve descripción de la misma. Estas pueden ser de los siguientes tipos: campamentos, deportes y juegos. De los campamentos interesa la ubicación y la duración en días, de los deportes interesa el tipo, los accesorios necesarios y la cantidad de horas semanales de entrenamiento, de los juegos interesa el tipo de juego, una descripción de las características y la cantidad de participantes. Cada colonia atiende a un conjunto de clientes, algunos de ellos asisten a más de una colonia. Nos interesa el número de cliente que lo identifica, nombre, C.I., teléfono y edad. Los clientes realizan diversas actividades, interesando la antigüedad con que las realizan. En el caso de los deportes, interesan también las fechas en las que el cliente participó en competencias. Los clientes sólo realizan actividades de las disponibles en su colonia. Se pide: Modelo Entidad Relación completo. Todos los atributos deberán aparecer en el diagrama Todas las relaciones deberán tener indicada su cardinalidad y deberá señalarse si la participación de las entidades es parcial o total. Deberán subrayarse los atributos eterminantes.Se deben formular las restricciones no estructurales. 

Ejercicio 2. Se quiere modelar la realidad relativa a una clínica odontológica. La clínica está compuesta por varios locales de atención, identificados por su nombre, de los cuales se conoce además su dirección dada por la ciudad donde se ubica, la calle y el número. En cada local existen varios consultorios que se identifican por un número dentro del local y en cada consultorio existe cierto equipamiento. El equipamiento se identifica globalmente mediante un número de serie, se conoce el tipo (torno, laser, etc.) e interesa mantener registro de la última fecha en que se le realizó mantenimiento. La clínica posee dos planes diferentes de afiliación: individual y grupal. De los afiliados se conoce la CI, el nombre y uno o más teléfonos. Para los afiliados grupales interesa saber el nombre del convenio de afiliación y el porcentaje de rebaja que se debe aplicar a la cuota mensual. En la clínica se realizan tratamientos, los cuales se identifican por su nombre y tienen un costo asociado. Los odontólogos que trabajan en la clínica se identifican por su nombre. De ellos se conoce su especialidad principal dentro de la odontología y los diferentes tratamientos que pueden realizar. Los odontólogos trabajan en diferentes locales y cada odontólogo puede tener distintos horarios de atención en cada local. De cada horario de atención se conoce el día de la semana, la hora de comienzo y la hora de finalización. (EJ: lunes de 16:00 a 18:30). Los afiliados se atienden con determinados odontólogos en determinado local y además los odontólogos les realizan tratamientos. Para que un paciente pueda recibir tratamiento de un odontólogo debe ser previamente atendido por este. Interesa mantener la historia clínica de cada afiliado, la Curso BD y Sistemas de Información Practico 1 – Modelo Entidad Relación Instituto de Computación – Facultad de Ingeniería – Universidad de la República Página 7 de 8 cual consiste, por un lado, en un registro de cada consulta indicando la fecha de consulta, el odontólogo y el local y por otro en un registro de todos los tratamientos que se le han realizado. De cada tratamiento interesa saber: fecha de inicio, si el tratamiento ha sido finalizado o no y la identificación del odontólogo que lo realizó, teniendo en cuenta que como política de la clínica un odontólogo sólo puede practicar un tratamiento por vez a cada afiliado. El inicio de un tratamiento, siempre se hace en una consulta. Para cada afiliado se mantiene una cuenta corriente donde se incluyen los costos de todos los tratamientos que han sido finalizados. Esta cuenta corriente es global a la clínica. Se pide: Modelo Entidad Relación completo. 

Ejercicio 11. Se desea realizar una base de datos geográfica. Los paises pueden clasificarse en países independientes y colonias. Las colonias pertenecen a algún país independiente. Estos últimos tienen alguna forma de gobierno que puede ser república, principado, emirato, democracia popular, dictadura, etc. Los países independientes comercian entre sí distintos productos. Las colonias sólo comercian con el país colonizador. En ambos casos, del producto comerciado se conoce un código que lo identifica, así como el nombre del producto. Las relaciones de comercio posibles son de importación y exportación de productos.También forma parte de la BD la información de límites entre países (qué países limitan con un país dado). Interesa modelar información relativa a los rios, los cuales pueden ser internacionales o nacionales. Los rios internacionales sirven de límite entre dos países mientras que los nacionales están totalmente contenidos en un sólo país. Los datos que interesan de cada río son su nombre, caudal y longitud. Se supone que pueden existir dos ríos nacionales con igual nombre en distinto país. Los ríos internacionales tienen nombre único. Se pide: Modelo Entidad Relación completo. Ejercicio 12. La O.M.C.M (Organización Mundial para el Control Marítimo) desea montar un sistema de información sobre el tráfico marítimo internacional. La información que le interesa mantener consiste en: Se tienen barcos (identificados por una matrícula) de los cuales interesa su bandera, nombre, tonelaje, calado y fecha de botadura. Los barcos pueden ser de pasajeros, de pesca o de carga. Los barcos de pasajeros tienen asociados la cantidad de pasajeros que pueden transportar. Los de pesca, el tipo de barco (atunero, de altura, etc.) y los de carga la capacidad de carga que pueden transportar. Curso BD y Sistemas de Información Practico 1 – Modelo Entidad Relación Instituto de Computación – Facultad de Ingeniería – Universidad de la República Página 8 de 8 Con respecto a los barcos de pesca, interesa tener la información de la zona de pesca en la que se encuentran trabajando. Un barco puede trabajar en muchas zonas y en una zona pueden haber trabajando varios barcos. Interesa saber en qué fecha estuvo un barco en una zona. Una zona de pesca está identificada por un código, tiene asociada un conjunto de coordenadas (latitud y longitud) de los puntos que la limitan y un conjunto de especies cuya pesca está permitida en la zona. Interesa saber qué zonas limitan con qué otras. Con respecto a los barcos de carga, interesa saber en qué puertos atracaron, la fecha en que lo hicieron y si cargaron o descargaron mercadería. No necesariamente un barco que atraca en un puerto debe hacerlo. Si hubo movimiento (cargo y/o descarga) interesa saber la cantidad asociada a cada operación. Las mercaderías están identificadas por un código y tienen asociada una unidad y su peso por metro cúbico. Los puertos están identificados por el nombre y el país, y tiene asociados la profundidad, los tipos de grúas que tiene, la capacidad en cantidad de barcos y si es de agua dulce o salada. Interesa también qué puertos están en cada zona de pesca (un puerto puede estar en varias).También interesa saber las distancias que existen entre los puertos. Se pide: Modelo Entidad Relación completo. Ejercicio 13. Se desea realizar el modelado de los datos necesarios para la distribución de los productos de un frigorífico, la cual se realiza desde su planta de procesamiento. Los clientes de frigorífico, que son carnicerías o mayoristas, realizan pedidos. El frigorífico conoce el nombre, dirección y RUC de sus clientes. También conoce la lista de los empleados de los mayoristas que están autorizados a recibir las entregas directamente. Los pedidos, que están numerados y fechados, consisten en una lista de varios cortes de productos cárnicos, en la que, por cada corte, se indica el número de piezas y el peso total aproximado. Los cortes reciben nombres identificatorios y se sabe que un corte puede formar parte de otros así como contener a otros cortes. Los distribuidores son intermediarios entre el frigorífico y los clientes (sean carnicerías o mayoristas). De ellos se conoce el nombre, la dirección y la lista de receptores autorizados a recibir entregas. Los distribuidores pueden atender a varios clientes y a su vez, un cliente puede ser atendido por varios distribuidores. Las entregas a los distribuidores y a los mayoristas, consisten en cargar un camión, de un único distribuidor o mayorista, con piezas de carne. Esta entrega, que está identificada con un número, se realiza en la planta del frigorífico, en cierta fecha, a individuos que se hacen responsables como receptores de la carga. La entrega de piezas a un distribuidor o mayorista se realiza contra un pedido realizado por un cliente. Más aun, el número de piezas entregada, su peso total (registrado en la balanza en el momento del embarque) y los cortes de éstas, deben corresponderse al del pedido. Sin embargo, pueden ser necesarias varias entregas para satisfacer un pedido, así como en una entrega se pueden satisfacer varios pedidos. Se pide: Modelo Entidad Relación completo.

DIAGRAMA DE ENTIDAD RELACION

DISEÑO DE UN ESQUEMA DE BASE DE DATOS E-R.

Podemos dividir el proceso de construir un modelo E-R en varias tareas más simples. 

El proceso completo es iterativo, es decir, una vez terminado debemos volver al comienzo, repasar el modelo obtenido y, probablemente, modificarlo. Una vez satisfechos con el resultado, será el momento de pasar a la siguiente fase: el modelo lógico.

Para crear un diagrama conceptual, realiza lo siguiente:

•      Habla con el cliente y deja claros los parámetros y objetivos del problema o proceso a modelar. 

•      Estudia el planteamiento del problema para: 

o   Identificar los conjuntos de entidades útiles para modelar el problema.

o   Identificar los conjuntos de interrelaciones y determinar su grado y tipo (1:1, 1: n o m: n). 

o   Trazar un primer diagrama E-R.  o Identificar atributos y dominios para los conjuntos de entidades y relaciones.  o Seleccionar las claves principales para los conjuntos de entidades. 

o   Verificar que el modelo resultante cumple el planteamiento del problema. Si no es así, se vuelve a repasar el proceso desde principio. 

Ejemplo 1

1.      Descripción del proceso

Se trata de una base de datos que debe almacenar datos sobre los suministros que ingresan los proveedores hacia un determinado almacén, para lo cual se debe llevar un control de los suministros y de sus cuentas contables.

2.      Identificar conjuntos de entidades

A primera vista, tenemos tres conjuntos de entidades: proveedor, suministro, cuenta contable.

3.      Identificar conjuntos de relaciones

Cada proveedor ingresa uno o más suministros, y estos pueden ser vendidos por uno o más proveedores, dándose una relación de muchos a muchos.

Por otra parte, estos suministros pertenecerán a una determinada cuenta contable, y esta cuenta contendrá múltiples suministros, dándose una relación de muchos a uno.

4.      Trazar primer diagrama 

3.      Identificar atributos

El siguiente paso es identificar los atributos para cada conjunto de entidades.

Alumno

•      Coralino

•      Nombre

•      Escuela 

•      Ciclo

Presta

•      Fecha presta

•      Fecha devolución

Libro

•      Codlibro

•      Registro

•      Titulo

•      Paginas

Especialidad

•      Codespecialidad

•      Nombre

Autor

•      Codautor

•      Nombre

•      Email

Editorial

•      Codeditorial

•      Nombre

•      Dirección

•      Teléfono

6.      Seleccionar claves principales

Un libro dispone de varias claves candidatas. Tenemos, por una parte, el codlibro, que es único para cada libro, y por otra su título, ya que no puede haber dos libros con el mismo título. Es lógico usar la primera como clave principal, ya que es un único atributo.

En el caso de alumno, especialidad, autor y editorial podemos tomar a codalumno, codespecialidad, codautor y codeditorial, como claves principales respectivamente.

Para el caso de presta, notamos que es una entidad compuesta que contará con las claves de alumno y libro respectivamente, además con sus atributos propios como fecha de préstamo y fecha de devolución.

7.      Verificar el modelo

Finalmente, el modelo E-R se presentará de la siguiente forma:

Modelados de Base De datos

Modelos de bases de datos

Un modelo de datos es la descripción de algo trillado como almacenador de datos, como los métodos de almacenar y recuperar datos de esos contenidos. Los modelos de datos no son físicas, son abstractos que permite la implementación de sistema eficiente de base de datos.por lo general se refiere a los algotitmos y conceptos matematicos.

Modelos constantemente utilizados en el modelado las bases de datos:

Bases de datos jerárquicas

En este modelo los datos se organizan en forma de árbol invertido o "raíz”: en donde un nodo padre de información puede tener varios hijos. El nodo que no tiene padres es llamado raíz, y a los nodos que no tienen hijos se los conoce como hojas.

Estos bases de datos son imprescindibles útiles en cao de aplicaciones que maneja un gran tamaño de información y datos compartidos permitido crear estructuras inmutables y de gran rendimiento.

Su principal inconveniente de este modelo es su incapacidad de representar evidentemente la renuncia de datos

Base de datos de red

Es un modelo ligero distinto al jerárquico. su diferencia principal es la mutabilidad del concepto de nodo; se permite que un mismo nodo tenga varios padres lo cual no está permitido en el jerárquico.

Es superior en gran manera con respecto al modelo jerárquico, ya que ofrecía una solución eficiente en el problema de repetición de datos, pero aun así sigue la dificultad de administrar la información.

Bases de datos transaccionales

Son base de datos cuyo objetivo es el envió y recepción de datos en grandes velocidades, estas bases son muy poco comunes y están dirigidas por lo general al entorno de analiza de calidad, datos de producción e industrial.su fin único es recolectar y recuperar los datos de mayor velocidad posible.La redundancia y la duplicación de información no es un problema como en los demás bases de datos nos permite algún tipo de conectividad con las bases de datos relacionales.

Un ejemplo habitual de transacción es el traspaso de una cantidad de dinero entre cuentas bancarias.

Bases de datos relacionales

Este es el modelo es más utilizado en la actualidad para representar problemas reales y administrar datos dinámicamente. Tras ser postulados sus fundamentos en 1970 por Edgar Frank Codd,2​ de los laboratorios IBM en San José (California). Su idea fundamental es el uso de "relaciones". Estas relaciones podrían considerarse en forma lógica como conjuntos de datos llamados "tuplas" Esto es pensando en cada relación como si fuese una tabla que está compuesta por registros (las filas de una tabla), que representarían las tupas, y campos (las columnas de una tabla).

La información puede ser recuperada o almacenada mediante "consultas" que ofrecen una amplia flexibilidad y poder para administrar la información.

El lenguaje más habitual para construir las consultas a bases de datos relacionales es SQL

Durante su diseño, una base de datos relacional pasa por un proceso  de normalización de una base de datos.

Bases de datos multidimensionales

son ideadas para  desarrollar aplicaciones muy concretas, como creación de Cubos OLAP.

no se diferencian demasiado de las bases de datos relacionales (una tabla en una base de datos relacional podría serlo también en una base de datos multidimensional), la diferencia está más bien a nivel conceptual;

En las bases de datos multidimensionales los campos o atributos de una tabla pueden ser de dos tipos, o bien representan dimensiones de la tabla, o bien representan métricas que se desean aprender.

Bases de datos orientadas a objetos

Este base de datos trata de almacenar los objetos completos (estado y comportamiento)

Es una base de datos que incorpora todos los conceptos importantes del paradigma de objetos:

Encapsulación - Propiedad que permite ocultar la información al resto de los objetos, impidiendo así accesos incorrectos o conflictos.

Herencia - Propiedad a través de la cual los objetos heredan comportamiento dentro de una jerarquía de clases.

Polimorfismo - Propiedad de una operación mediante la cual puede ser aplicada a distintos tipos de objetos.

Los usuarios pueden definir operaciones sobre los datos como parte de la definición de base de datos

Una operación (llamada función) se especifica en dos partes. La interfaz (o signatura) de una operación incluye el nombre de la operación y los tipos de datos de sus argumentos (o parámetros). La implementación (o método) de la operación se especifica separadamente y puede modificarse sin afectar la interfaz.

.

Bases de datos documentales

Nos permite la indexación a texto completo, realiza búsqueda más robustos, sirve para almacenar grandes volúmenes de información de antecedentes históricos

Bases de datos deductivas

Es sistema de base de datos con la diferencia de que permite deducciones atravesó de inferencia.

se basa principalmente en las reglas y hechos que son almacenados en la base de datos. Las bases de datos deductivas o lógicas se basan e lógica matemática, surge debido a las limitaciones de la Base de Datos Relacional de responder a consultas recursivas y de deducir relaciones indirectas de los datos almacenados en la base de datos.

Lenguaje

Utiliza un subconjunto del lenguaje Prologa llamado Data log el cual es declarativo y permite al ordenador hacer deducciones para contestar a consultas basándose en los hechos y reglas almacenados.

Ventajas

Uso de reglas lógicas para expresar las consultas.

Permite responder consultas recursivas.

Cuenta con negaciones estratificadas

Capacidad de obtener nueva información a través de la ya almacenada en la base de datos mediante inferencia.

Uso de algoritmos que optimizan las consultas.

Soporta objetos y conjuntos complejos.

Fases

Fase de Interrogación: se encarga de buscar en la base de datos informaciones deducibles implícitas. Las reglas de esta fase se denominan reglas de derivación.

Fase de Modificación: se encarga de añadir a la base de datos nuevas informaciones deducibles. Las reglas de esta fase se denominan reglas de generación.

Interpretación

Encontramos dos teorías de interpretación de las bases de datos deductiva por lo cual consideramos las reglas y los hechos como axiomas. Los hechos son axiomas base que se consideran como verdaderos y no contienen variables. Las reglas son axiomas deductivos ya que se utilizan para deducir nuevos hechos.

Teoría de Modelos: una interpretación es llamada modelo cuando para un conjunto específico de reglas, estas se cumplen siempre para esa interpretación. Consiste en asignar a un predicado todas las combinaciones de valores y argumentos de un dominio de valores constantes dado. A continuación, se debe verificar si ese predicado es verdadero o falso.

Mecanismos

Existen dos mecanismos de inferencia:

Ascendente: donde se parte de los hechos y se obtiene nuevos aplicando reglas de inferencia.

Descendente: donde se parte del predicado (objetivo de la consulta realizada) e intenta encontrar similitudes entre las variables que nos lleven a hechos correctos almacenados en la base de datos.

Sistema de Gestión de bases de datos distribuida (SGBD)

La base de datos y el software SGBD pueden estar distribuidos en múltiples sitios conectados por una red. Hay de dos tipos:

1. Distribuidos homogéneos: utilizan el mismo SGBD en múltiples sitios.

2. Distribuidos heterogéneos: Da lugar a los SGBD federados o sistemas cultivase de datos en los que los SGBD participantes tienen cierto grado de autonomía local y tienen acceso a varias bases de datos autónomas preexistentes almacenados en los SGBD, muchos de estos emplean una arquitectura cliente-servidor.

Estas surgen debido a la existencia física de organismos descentralizados. Esto les da la capacidad de unir las bases de datos de cada localidad y acceder así a distintas universidades, sucursales de tiendas, etc.

Biografia

                                           RAMOS CENTENO, JOSH LUIS

Nació el 04 de abril de 1999, Estudio el nivel primario en PABLO BASILIO AUQUI "Liderando el cambio”, donde muchos de los poetas, médicos, maestros, abogados, ingenieros y militares se formaron en el profundo de nuestro Perú querido, curso el nivel secundario en el colegio” AUGUSTO SALAZAR BONDY". cuna Filósofos y poetas, logrando excelentes calificaciones, siendo el primer alumno destacando en el mundo de la literatura y poesía. Estudio Ingeniería de Software en la Universidad Nacional del Huancavelica del donde tuvo como maestros al Dr. Gilmer Matos Vila, Dr.JHONNY ANIBAL VILCA MORENO . 

Especializándose en analista de Base de datos en los gestores de base de Datos tales como SQL Server, MySQL, Oracle, PostgreSQl, Access y en el mundo de la programación en los lenguajes de programación tales como Java,Phyton,C#,Vb.net y en el mundo de Inteligencia Artificial.

Conocedor del mundo de la informática y el uso de las TICS (Tecnologías de Información y Comunicación) y el IOT (Internet de las cosas).

Frases celebre:

El espíritu de la perseverancia en tu vida que no se apague, no la permitas que se apague  en  ti.

Recuerda que viniste a este mundo  con un propósito, recuerda  no lo olvides eres el ser más valioso.

Estudia, estudia y estudia solo el te sacara del mundo de la ignorancia, este país necesita hombres y mujeres con pasos firmes.

Si hoy caiste,nunca vuelves a cometerlo busca la manera de levantarse sabiamente

Estudio, Dios y Patria.        

CLASIFICACION DE BASE DE DATOS

Clasificación de bases de datos

Se clasifican de varias maneras según el contexto en donde ese esté realizando y según que satisfaga las necesidades 

Según la variabilidad de la base de datos

Bases de datos estáticas

Son las bases de datos solamente de lectura, que son utilizadas para almacenar un conjunto de datos históricos que posteriormente se pueda utilizar para realizar proyecciones, toma de dicciones y el análisis de datos para la inteligencia empresarial, por ejemplo. La cantidad de ventas  de productos lácteos  que realizo  la empresa "JAIMITO & CENTER" ,el año pasado a partir de ello tomamos la decisiones  a partir del punto de equilibrio de los ingresos y egresos de la empresa.

Bases de datos dinámicas

Son las bases de datos donde la información almacenada se cambia al paso del tiempo, permitiendo operaciones como la actualización, eliminación y edición de datos, realizando las operaciones fundamentales de consulta. Un ejemplo el base de datos utilizados en un sistema de información de una farmacia.

Según el contenido

Bases de datos bibliográficas

Solo contiene una subrogante de la fuente primaria que permite localizarla. Un registro tradicional de una base de datos bibliográfica contiene información sobre el autor, fecha de publicación, editorial, título, edición, de una determinada publicación, etc. Puede contener un resumen o extracto de la publicación original, pero nunca el texto completo. Un ejemplo una colección de artículos de investigación científica acerca plantas sus efectos medicinales.

Bases de datos de texto completo

Almacena las fuentes primarias como los artículos de investigación científica

Bases de datos o "bibliotecas" de información química o biológica

Son bases de datos que almacenan diferentes tipos de información proveniente de la química, las ciencias de la vida o médicas. Se pueden considerar en varios subtipos: