* Has entrado en #mononeurona.org
* El topic para #mononeurona.org es ¡Bienvenid@ a la Mononeurona! || ¡Despabila tu mononeurona y comparte tu conocimiento! || Registra tu nick: "/msg nickserv register your-password" || Sandbox: http://mononeurona.org.pastebin.com || Vista la página oficial: http://www.mononeurona.org/ || Date de alta y sé parte del selecto grupo.
* Topic para #mononeurona.org definido por asarch en Wed Apr  2 16:03:23 2008
* #mononeurona.org :[freenode-info] why register and identify? your IRC nick is how people know you. http://freenode.net/faq.shtml#nicksetup
<Hrgn> o me equivoque de mundo?
<Hrgn> jejejeje
<azimov> aqui es
<azimov> ya llegó el profe
<rnstux> buenas nuevas!
<rnstux> >(
<rnstux> dejen configuro el teclado
<Hrgn> buenas....tu eres el profe rnstux?
<rnstux> :)
<rnstux> Listo
<rnstux> Así es.. Que paso leyeron el log?
<rnstux> Alguna duda?
<azimov> todo bien
<Jose8017> no
<Jose8017> dale con la charla de ahora
<Hrgn> si lo lei, mas o menos
<rnstux> Ok!
<rnstux> Comenzamos..
<rnstux> Bien recordando..Las correspondencias de cardinalidades son 4
<rnstux> Uno  a Uno
<rnstux> Uno a muchos
<rnstux> Muchos a Uno
<rnstux> Y muchos a muchos
<rnstux> Dijimos que las relaciones N:N..no se pueden representar lógicamente en la base de datos
<rnstux> Y generalmente las relaciones Uno a Uno..tampoco se representa en el diagrama E-R
<Hrgn> ok
<rnstux> Por que?..
<rnstux> Pues si tenemos la relacion:   Un alumno tiene una foto (La de la credencial)
<rnstux> En lugar de manejar la Foto..como entidad la podemos manejar como un atributo de la entidad alumno
<rnstux> Así nos ahorramos una tabla :)
<Jose8017> asi es
<Jose8017> pero a veces es necesario otra tabla
<rnstux> A veces!
<rnstux> Depende de como te lo indiquen
* monouser2144782 (n=monouser@201.137.208.253) ha entrado en #mononeurona.org
<Jose8017> y ahi se hay que representar la relación 1:1
<rnstux> bueno como gusten :) si les gusta usar muchas tablas o la lógica del negocio asi lo pide
<Jose8017> hay veces en las que la relacion de una entidad es 1:1 para 1 entidad y 1:n para otra entidad en el mismo diagrama
<rnstux> Dentro del analisis del problema es necesario identificar si puede ser una Entidad o Mejor lo manejamos como un atributo
<rnstux> Así es depende de la lógica del negocio como lo mencione
<Jose8017> ok
<rnstux> Bien..pero si tenemos que: La entidad Empleado
<rnstux> Puede tener muchos Emails
<rnstux> Es decir empleado tiene muchos emails.
<rnstux> Podemos manejara como entidad a Email. y crear una tabla en la Base de datos.
<rnstux> Pero lo podemos manejar como atributo tambien...
<rnstux> Como!!!!
<rnstux> Bueno...Podemos crear una atributo email para empleado y dentro de este atributo...Almacenar todos los emails separados por comas...
<rnstux> rnstux@gmail.com, rnstux2@hotmail.com, rnstux@yahoo.com
<rnstux> Y tambien nos ahorramos una tabla :)
<rnstux> Alguna duda?
<azimov> ya entiendo
<rnstux> jaja! pregunten o pensare que le estan entendiendo a todo
<rnstux> O a nada :;P
<azimov> jeje
<rnstux> Bueno..ahora hablemos de la dependencia de existencia
<rnstux> Por ejemplo... Entidad Producto y entidad Cliente
<rnstux> Es una relacion N:N...muchos a muchos y como dijimos.. la tenemos que descomponer
<rnstux> En relaciones Uno a muchos
<rnstux> Y que así con ASCII ART :P
<rnstux> PRODUCTO 1------------------N----VENTAS-------N--------------------1---CLIENTE
<rnstux> La tabla ventas depende de que antes exista la tabla Producto y la Tabla CLiente
<rnstux> Las tenemos que crear primero...
<rnstux> Pero que pasa si....Queremos cambiar el nombre de un producto...
* chilicuil (n=javier@189.145.48.243) ha entrado en #mononeurona.org
<rnstux> Es decir.. Tenemos Galletas Mairas...es Es Galletas Marias.
<rnstux> Los cambios tambien se tienen que realizar en la tabla Ventas.-..
<rnstux> Ya que nos generaria incosistencias en la BD
<rnstux> AL realizar una cambio en producto automaticamente se realiza en Ventas.
<rnstux> Que recibe el nombre de actualizacion en cascada :)
<rnstux> Y al reves..en la tabla Ventas no podemos...Agregar un producto que no existe en la tabla Productos :)
<rnstux> Es decir la tabla Ventas tiene una dependencia Total de la tabla Producto...
<azimov> ventas puede ser el costo del producto?
<rnstux> No!!
<rnstux> La tabla ventas solo me dice que producto vendi, a quien y que cantidad vendi de ese producto
<azimov> ah ok
<rnstux> El costo es un atributo de la tabla Producto
<Hrgn> y cuantas me quedan
<rnstux> Por lo tanto debe estar en Producto
<rnstux> Cuantas que?
<rnstux> @Hrgn: Cuantas que?
<rnstux> ....
<rnstux> Creo  que continuamos jeje!
<rnstux> Ok?
<Hrgn> existencias de galletas
<Hrgn> que en ventas podemos sabes cuantas galletas me quedan
<Hrgn> jejejeje
<rnstux> No!
<rnstux> La existencia no depende de las ventas..
<rnstux> La existencia es un atributo de un producto y por lo tanto debe ir en producto
<rnstux> Los atributos de producto son: Nombres, PrecioUnitario, PrecioCaja, Existencia, StockMinimo, etc...
<rnstux> Los atributos de clientes..son: Nombre, Direccion, Telefono,RFC..etc
<Hrgn> ok
<rnstux> Y de Ventas:    IdCliente, IdProducto, Cantidad
<rnstux> Cuando hablemos de normalizacion lo entenderas :)
<rnstux> Bien...Hablemos de llaves o claves :)
<rnstux> Una llave o clave..Nos sirve para identificar de manera unica y exclusiva a una entidad
<rnstux> Evitando que haya duplicidad de registros en la base de datos
<rnstux> Tenemos los siguientes tipos de llaves: Candidatas, Primarias, Superllaves, Extranjeras, Secundarias..
<rnstux> Las claves candidatas son aquellas que podrian identificar de forma unica a un registro.
<rnstux> Algunos ejempplos:  La Curp, RFC, Numero de Seguro social, Numero de telefono, clave IFE
<rnstux> Las clave primaria es: La elegida dentro de las claves candidatas...Y nos sirvira para identificar a cada registro en la tabla de la BD
<rnstux> Y la superllave..es la combinacion de dos o mas claves primarias...Y se utilizan cuando un entidad no puede generar su propia clave primaria..
<rnstux> Aqui es donde entra lo de las entidades debiles: @Jose8017
<rnstux> :)
<rnstux> Las llaves extranjeras: Son claves primarias de otra entidad que nos permiten crear las relaciones entre entidades
<rnstux> Y las secundarias..son llaves que podemos utilizar con fines de ordenamiento :)..
<rnstux> todo bien?
<azimov> si, estoy tomando nota
* Almsx (n=Almsx@189.143.95.64) ha entrado en #mononeurona.org
<Almsx> hola a todos
<Almsx> disculpen la tardanza jeje
<rnstux> Que tal!
<rnstux> Creo que varios estan..algo atrazados!
<rnstux> Esperamos o nos seguimos de largo
<rnstux> ?
<Almsx> jeje
<chilicuil> adelante
<Almsx> adelante rnstux
<Almsx> por favor
<Almsx> alguien lleva el log verdad?
<rnstux> Yo
<rnstux> :P
<Almsx> ok :P
<rnstux> Pero por las dudas..alguien mas
<rnstux> !
<azimov> continuamos
<rnstux>  La Curp, RFC, Numero de Seguro social, Numero de telefono, clave IFE...Estas son nuestras claves candidatas
<rnstux> Pero como hacemos para elegir..
<rnstux> Siguiendo estas reglas: La clave primaria deber ser:
<rnstux> Atributo Univalorado, No permite valores nulos, Tener longituda mínima.
<rnstux> Descartamos en número de telefonico..Por que puede llegar a ser nulo..Es decir una persona puede no tener un telefono
<rnstux> El RFC..no es muy confliable por que puede llegara repetirse!
<rnstux> El número del IMSS...Puede ser nulo ya que hay personas que no estan inscritas a esta institución al igual que  la del IFE
<azimov> La llave primaria es el CURP?
<rnstux> Nos quedamos con la CURP.aunque es muy larga....Si hubiera otra manera de generar la clave primaria la tomanos..o si el negocio ya tiene como identificar a los clientes
<rnstux> en este caso si...
<rnstux> Pero tambien la clave primaria pudo haber sido..de tipo Serial
<rnstux> Es decir... 1,2,3,4,5...N
<rnstux> Y es válido, práctico y mas fácil de procesar por el sistema gestor de bases de datos
<rnstux> Cuestion de estilos y de requerimientos de la BD.
<rnstux> O pudo haber quedado tambien.
<rnstux> Cli01,Cli02,Cli03....CliN
<rnstux> Y es un poco mas clara..Nos indica que la llave pertenecer a un Cliente
<rnstux> Ok?
<azimov> si
<rnstux> bueno!
<Hrgn> ok
<rnstux> No explicare a detalle el Modelo Relacional
<rnstux> Es muy similar al Entidad Relacion..
<rnstux> Solo mencionare unos conceptos
<rnstux> Una tabla en el modelo relacional es..Un conjunto
<rnstux> Una fila o registro: es una tupla
<rnstux> Dominio..Es Conjunto de posibles valores para cada atributo
* n3rg4r (i=bd86daf9@gateway/web/ajax/mibbit.com/x-77d444640e498071) ha entrado en #mononeurona.org
<rnstux> Ejemplo..Calificacion tiene el siguiente dominio:  5-10...No puede ser 11,
<rnstux> Por ejemplo..si alguna ves..Quieren subir un punto a  sus alumnos...y esta almacenado en la tabla calificaciones
<rnstux> Si hay un alumno que tiene un 10...Automaticamente....nos debe mostrar un bonito error :)
<rnstux> un ejercicio para al rato :)
<rnstux> ...
<rnstux> “Una empresa vende productos a varios clientes. Se necesita conocer los datos
<rnstux> personales de los clientes (nombre, apellidos, dni, dirección y fecha de nacimiento). Cada
<rnstux> producto tiene un nombre y un código, así como un precio unitario. Un cliente puede
<rnstux> comprar varios productos a la empresa, y un mismo producto puede ser comprado por
<rnstux> varios clientes.
<rnstux> Los productos son suministrados por diferentes proveedores. Se debe tener en cuenta
<rnstux> que un producto sólo puede ser suministrado por un proveedor, y que un proveedor puede
<rnstux> suministrar diferentes productos. De cada proveedor se desea conocer el NIF, nombre y dirección”.
<rnstux> Lo hacen cuando tengas tiempo
<azimov> ok
<rnstux> Y tiene que: Identificar entidades, relaciones, atributos, clasificar atributos(univalorados, multivalorados, etc)
<rnstux> Claves primarias y tipos de datos.
* n3rg4r se ha marchado ("http://www.mibbit.com ajax IRC Client")
<azimov> ok
<rnstux> Ok! luego me manda su tarea..haber si le entendieron
<azimov> ok
<rnstux> tengo mas ejercicios para el que guste :P
<rnstux> Ahora si entramos a Normalización
<rnstux> Se oye complicado pero es muy fácil!
<rnstux> Primero que es la normalizacion:
<rnstux> Pues..es un proceso de refinamiento de la estrutura de la BD....
<rnstux> COn el fin de mejorar la velocidad de acceso a estos...y así tambien mejorar su integridad
<rnstux> Bien existen una reglas llamadas formas normales
<rnstux> Y se identifican asi
<rnstux> 1FN: Primera Forma Normal!
<rnstux> Y dice asi.:
<rnstux> 1FN: Todas las tablas deben tener una clave primaria, Eliminar grupos repetitivos dentro de la tabla
<rnstux> Ejemplo: lo de la clave primaria esta muy claro..veamos lo de grupos repetitivos
<rnstux> Supongamos que tenemos La entidad Estudiante que tiene los sig. atributos.
<rnstux> Nombre, Apellido, Carrera, Semestre...y ademas queremos saber los deportes que practica
<rnstux> Podemos tener 3 campos en la tabla Estudiante.. denominados asi. Deporte1,Deporte2, Deporte3.
<rnstux> Y la tabla queda asi:
* ciBAt (n=ciBAt___@dsl-200-67-251-97.prod-empresarial.com.mx) ha entrado en #mononeurona.org
* ChanServ da OP a ciBAt
<rnstux> Nombre, Apellido, Carrera, Semestre,  Deporte1,Deporte2, Deporte3
<rnstux> Aquí existe un problema...Que pasa si el alumno no practica ningun deporte..estamos desperdiciando..3 campos en la base de datos.
<rnstux> Y ademas que pasa si el alumno..practica mas de 3 deportes..
<rnstux> Y empleamos la primera forma normal:
<rnstux> entonces podemos poner el alumno y que deporte practica:
<rnstux> en otra tabla:
<rnstux> La tabla estudiante nos queda asi: Id, Nombre, Apellido, Carrera, Semestre
<rnstux> y la tabla deportes queda asi: IdDeporte, Descripcion, IdEstudiante
<rnstux> los posibles datos de estudiante pueden ser:      1, Futbol, 0148
<rnstux> 2, Futbol, 0179
<rnstux> 2, Beisbol, 0147
<rnstux> 2, Matatenas , 0151
<rnstux> El primer valor es: La clave de deporte, luego el tipo de deporte...y luego la clave del estudiante que lo practica
<rnstux> logicamente primero debe existir esa clave en la tabla estudiante..
<rnstux> OK?
<rnstux> Ya me duelen los dedos :( Este teclado esta muy duro jajaja!
<Hrgn> jejjeje
<rnstux> Dudas?
<azimov> Hasta ahorita no
<rnstux> Ok! ya cumplimos la primera forma normal
<rnstux> Otro ejemplo puede ser: que tenga muchas direcciones..
<rnstux> direccion1, direccion2, direccion3
<rnstux> O muchos telefonos o muchos correos..
<rnstux> Hacemos lo mismo!
<azimov> ok
<rnstux> Bueno..vamos con la 2FN..segunda forma normal
<rnstux> 2FN: Dice..eliminar datos redundantes!
<rnstux> 1, futbol, 0148
<rnstux> 2, Futbol, 0179
<rnstux> 2, Beisbol, 0147
<rnstux>  3, Matatenas , 0151
<rnstux> 4, Beisbol, 0160
<rnstux> Que notan ahi?
<azimov> futbol y Futbol
<Hrgn> eso, eso
<rnstux> así es
<azimov> los Id de Beisbol
<azimov> son diferentes
<rnstux> Por ejemplo supongan que tenemos que ver cuantos estudiantes, practican futbol
<rnstux> Postgres diferencia Mayuscular de minuscular
<rnstux> Por lo tantto futbol y Futbol
<rnstux> Son diferentes..nos genera inconsistencia en la BD..y en los resultados de la consulta
<rnstux> :) otra cosa que se nota.. es que estamos repitiendo los deportes.
<rnstux> La palabra futbol puede aparecer cientos de veces..estoes un desperdicio de espacio en nuetro querido disco duro.
<rnstux> Entonces eso no se debe hacer..!!
<rnstux> 2FN: dice
<rnstux> Eliminar grupos repetitivos
<rnstux> Como lo solucionamos..
<rnstux> Con..pues con otra tabla.,
<rnstux> SI la relacion es..Un alumno puede practicar muchos deportes(O ninguno), y un deporte puede ser practicado por muchos alumnos
<rnstux> Creamos una tabla intermedia...llamda... Estudiante-Deporte
<rnstux> y nos queda asi
<rnstux> Estudiante 1--------------------N----Estudiante-Deporte----N------------------------1--Deportes
<rnstux> Los atributos quedan asi.
<rnstux> Estudiante: Nombre, apellidos, semestre, carrera
<rnstux> ah! y tambien IdEstudiante :P
<rnstux> Y en Deporte:  IdDeporte, Descripcion
<rnstux> Y en Deporte-Estudiante: IdEstudiante, IdDeporte
<rnstux> Con datos...queda asi:
<rnstux> Estudiante: Edgar, Hernandez XX, 7, Informatica
<rnstux> Estudiante: Jose, Lopez Cruz, 9, Informatica
<rnstux> Estudiante: Arturo, Perez Perez, 5, Administracion
<rnstux> y en deportes:
<rnstux> fut, futbol
<rnstux> bas, basquetbol
<rnstux> vol, voleibol
<rnstux> nat, Natacion
<rnstux> Kar, Karate
<rnstux> La clave primaria es los 3 primero digitos del nombre del deporte
<rnstux> Chin...Me faltaron los IDS en la tabla estudiante :P
<rnstux> jaja! bueno los IDS son:  0147, 0145, 0165, 0150 (Asi lo hacen en mi escuela, jajaja!)
<azimov> teniendo la clave primaria en los deportes, ya no es necesario los Id's?
<rnstux> Id= Clave Primaria
<azimov> ok
<rnstux> Bien...en la tabla: Estudiante-Deporte: IdEstudianteDeporte, IdEstudiante, IdDeporte
<rnstux> Y con datos asi..:    0147kar, 0147, kar
* Almsx se ha marchado ("Saliendo")
<rnstux> 0147fut, 0147, fut
<rnstux> 0145fut, 0145, fut
* Hrgn se ha marchado (Remote closed the connection)
* monouser248756 (n=monouser@dsl-200-67-177-176.prod-empresarial.com.mx) ha entrado en #mononeurona.org
<rnstux> Y formamos una super clave con...Las claves de estudiante y de deporte
<rnstux> Y ahi nos indica..que estudiante y que deporte practica..
<rnstux> Tambien solo pudimos haber almacenado la superclave...y separlalo para saber el id del estudiante y el id de deporte
<rnstux> O pudo haber tenido su propia clave primaria...
<rnstux> De tipo serial
<rnstux> 1,2,3,4,.....N
<rnstux> Ok?
<rnstux> jaja! Quien queda?
* Hrgn (n=Mario@189.131.187.138) ha entrado en #mononeurona.org
<rnstux> ?
<rnstux> Bueno con fines de LOG...seguire con las otras formas normales
<rnstux> ..
<rnstux> 3FN..Dice..Eliminar columnas que no tengas que ver con la clave primaria
<rnstux> Ejemplo si tenemos Una tabla de productos y en ella
<rnstux> tenemos la fecha en que se vendio el producto.
* nergar se ha marchado (Remote closed the connection)
<rnstux> Esta no tiene relacion con la clave primaria..Ya que la fecha de venta pertenece a la tabla ventas
* Nergar (n=Nergar@189.141.119.70) ha entrado en #mononeurona.org
* ChanServ da OP a Nergar
<rnstux> Perdon a la tabla productos.
<rnstux> Por lo tanto fecha de venta tiene que estar en ventas no en productos..
<rnstux> Al igual que..Existencias debe estar en producto como no en ventas
<Nergar> arhg!!! acaba de crashear Opera, ya no va a haber log bonito a colores :(
<rnstux> Chin..pero va a haberlog..feito.. :P
<Nergar> :)
<rnstux> Aqui solo hay que ver si ese atributo en realidad corresponde a esa tabla si no.
<rnstux> lo cambiamos..
<rnstux> Esta esta fácil..
<rnstux> La cuarta forma normal dice
<rnstux> 4FN: No almacenar datos calculados en las tablas
<rnstux> Cuales son los datos calculados....facil. aquellos que podemo saber.
<rnstux> con solo calcular..
<rnstux> :P
<rnstux> Ejemplo... Edad lo podemos obtener de fecha de nacimiento,
<rnstux> Importe: lo Obtenemos de multiplicar el Precio por la cantidad de que se compro
<rnstux> Promedio..Lo podemos calcular sumando las calificaciones y dividiendolas
<rnstux> Etc.
<rnstux> AH lo olvidaba... :P la normalizacion exige que los datos deben ser atomicos
<rnstux> Es decir que no se puedan dividir en mas datos.
<rnstux> Por ejmplo: Apellidos se compone de Apellidos Paterno + Apellido Materno
<rnstux> Siguiendo las FN...tendriamos que crear un campo.. ApellidoPaterno y otro ApellidoMaterno
<rnstux> AL igual que direccion.
* azimov se ha marchado (Read error: 113 (No route to host))
<rnstux> y la 5FN..Dice aislar las multiples relaciones conexas..
<rnstux> Que quiere decir, si una persona tiene: Muchos telefonos, muchas direcciones, muchos correos, muchos hijos.
<rnstux> Toda esta informacion debe ir en otras tablas.
<rnstux> Bueno con esto se temina lo de normalizacion!
<rnstux> Y sino hay dudas...pues terminamos..
<rnstux> Aun falta mucho, pero a partir de aqui ya podemos comenzar a trabajar con SQL
<rnstux> Quien anda por ahi todavia?
<Hrgn> ok
<rnstux> Queda pendiente el curso de SQL..
<rnstux> Otro ejercicio:
<rnstux> “La clínica “SAN PATRÁS” necesita llevar un control informatizado de su gestión de
<rnstux> pacientes y médicos.
<rnstux> De cada paciente se desea guardar el código, nombre, apellidos, dirección, población,
<rnstux> provincia, código postal, teléfono y fecha de nacimiento.
<rnstux> De cada médico se desea guardar el código, nombre, apellidos, teléfono y especialidad.
<rnstux> Se desea llevar el control de cada uno de los ingresos que el paciente hace en el hospital.
<rnstux> Cada ingreso que realiza el paciente queda registrado en la base de datos. De cada
<rnstux> ingreso se guarda el código de ingreso (que se incrementará automáticamente cada vez
<rnstux> que el paciente realice un ingreso), el número de habitación y cama en la que el paciente
<rnstux> realiza el ingreso y la fecha de ingreso.
<rnstux> Un médico puede atender varios ingresos, pero el ingreso de un paciente solo puede ser
<rnstux> atendido por un único médico. Un paciente puede realizar varios ingresos en el hospital”.
<rnstux> Identificar..Entidade,Relaciones,Clasificar los atributos, normalizar
<rnstux> Ademas identificar tipos de datos
<rnstux> caracter, booleano, entero, real, etc.
<rnstux> @Hrgn->Me voy, tengo una cita ;)
<Hrgn> ok
<Hrgn> cuando seguiria esto?
<rnstux> Pues!
<rnstux> Cuando el público lo pida
<rnstux> Mientras este en vacaciones
<rnstux> Puede ser la sig.semana
<rnstux> Checare en estos dias.
<Hrgn> ok, pon el dia y la hora que mas te convenga
<rnstux> Ok!..
<rnstux> bueno me voy! nos vemos!
<rnstux> queda pendiente SQL
<Hrgn> ok
<rnstux> nada mas jeje!
<rnstux> adios
<Hrgn> no podria ser en Acces?
<Hrgn> jejejejejejjejejejejejejjjjjjjjjjeeeeeeeeee
<rnstux> Ja!
<rnstux> SQL..es universal!
<Hrgn> no, es cierto una pequeña broma
<rnstux> :P Acces no se apega mucho a estandar
<rnstux> jaja!
<rnstux> Mejor Postgres
<rnstux> jajajajajaja!
<Hrgn> mySQL
<rnstux> Maybe!
<rnstux> No cambia mucho
<rnstux> Ok! sale te cuidas
<rnstux> ahora si ya me voy...me esperan
<Hrgn> ok