Codigo Oracle AMIGOS Y CERVEZA

 SE CREA LA TABLA AMIGO. ENCABEZADO CON CREATE, LOS ATRIBUTOS Y SUS TIPOS. LA LINEA QUE DICE CONSTRAINT AMIGO ... SE SEÑALA IDAMIGO COMO LA PK

CREATE TABLE AMIGO

 (

   IDAMIGO NUMBER,

   NOMBRE VARCHAR2(30),

   APELLIDO VARCHAR2(30),

   TELEFONO NUMBER,

   EMAIL VARCHAR2(50),

   TWITTER VARCHAR2(30),

   FECHANACIMIENTO DATE,

   CONSTRAINT AMIGO_PK PRIMARY KEY(IDAMIGO) ENABLE

 );

 SE CREA LA TABLA CERVEZA CON SUS ATRIBUTOS Y PK.

CREATE TABLE CERVEZA

 (   

   IDCERVEZA NUMBER,

   NOMBRE VARCHAR2(20),

   MARCA VARCHAR2(10),

   CONSTRAINT CERVEZA_PK PRIMARY KEY (IDCERVEZA) ENABLE

 );

  

 SE CREA TABLA PRUEBA, CON ATRIBUTOS Y PRIMARY KEY. LAS DOS LINEAS QUE DICEN CONSTRAINT PRUEBA_FK ... SEÑALA LAS LLAVES FORANEAS (FK). DICEN QUE POR EJEMPLO, IDCERVEZA SERA LO MISMO QUE LA PK IDCERVEZA DE LA TABLA CERVEZA. MEDIANTE ESO SE UNEN LAS TABLAS AMIGO, PRUEBA Y CERVEZA.

CREATE TABLE  PRUEBA

 (   

   IDPRUEBA  NUMBER,

   IDAMIGO   NUMBER,

   IDCERVEZA NUMBER,

   CONSTRAINT PRUEBA_PK PRIMARY KEY (IDPRUEBA) ENABLE,

   CONSTRAINT PRUEBA_FK_AMIGO FOREIGN KEY (IDAMIGO) REFERENCES  AMIGO (IDAMIGO) ENABLE,

   CONSTRAINT PRUEBA_FK2_CERVEZA FOREIGN KEY (IDCERVEZA) REFERENCES  CERVEZA (IDCERVEZA) ENABLE

 );

 SE CREA LA TABLA BAR, CON SUS ATRIBUTOS Y PK.

CREATE TABLE BAR

 (

   IDBAR NUMBER,

   NOMBRE VARCHAR2(25),

   DIRECCION VARCHAR2(50),

   COMUNA VARCHAR(20),

   TELEFONO NUMBER,

   CONSTRAINT BAR_PK PRIMARY KEY(IDBAR) ENABLE

 );

 SE CREA TABLA FRECUENTA, CON ATRIBUTOS, PK Y 2 FK. CON ESTO UNEN AMIGO, FRECUENTA Y BAR. ADEMAS EN EL ULTIMO CONSTRAINT FRECUENTA_HORARIO ... SE USA COMO UNA VALIDACION. MECIONA QUE EL ATRIBUTO HORARIO SOLO PODRA RECIBIR LOS VALORES MAÑANA, TARDE, NOCHE O INDIFERENTE.

CREATE TABLE FRECUENTA

 (

   IDFRECUENTA NUMBER,

   IDAMIGO NUMBER,

   IDBAR NUMBER,

   HORARIO VARCHAR2(10),

   CONSTRAINT FRECUENTA_PK PRIMARY KEY(IDFRECUENTA) ENABLE,

   CONSTRAINT FRECUENTA_FK_AMIGO FOREIGN KEY (IDAMIGO) REFERENCES  AMIGO (IDAMIGO) ENABLE,

   CONSTRAINT FRECUENTA_FK2_BAR FOREIGN KEY (IDBAR) REFERENCES  BAR (IDBAR) ENABLE,

   CONSTRAINT FRECUENTA_HORARIO CHECK (HORARIO IN ('MAÑANA', 'TARDE', 'NOCHE', 'INDIFERENTE')) ENABLE

 );

 CREA TABLA SIRVE, CON SUS ATRIBUTOS, PK Y SUS 2 FK. SE CREA LA CONEXION BAR, SIRVE, CERVEZA.

CREATE TABLE SIRVE

 (

   IDSIRVE NUMBER,

   IDBAR NUMBER,

   IDCERVEZA NUMBER,

   CONSTRAINT SIRVE_PK PRIMARY KEY(IDSIRVE) ENABLE,

   CONSTRAINT SIRVE_FK_CERVEZA FOREIGN KEY (IDCERVEZA) REFERENCES  CERVEZA (IDCERVEZA) ENABLE,

   CONSTRAINT SIRVE_FK2_BAR FOREIGN KEY (IDBAR) REFERENCES  BAR (IDBAR) ENABLE

 );

 ACA SE POBLA LA TABLA AMIGO, ES DECIR, SE LE AGREGAN DATOS. EL BEGIN Y EL END HACEN QUE SE PUEDAN AGREGAR TODOS LOS DATOS DE UNA VEZ.

Begin

Insert into Amigo values (10, 'Pedro', 'Picapiedra', 5555555, 'ppicapiedra@gmail.com','@Picapiedra', '06/06/1966');

insert into Amigo Values (20, 'Rick', 'Wackeman', 932456765, 'rwackeman@hotmail.com', '@wackeman', '25/05/1960');

insert into Amigo Values (30, 'Jack', 'Bauer', 74859632, 'jbauer@ctu.org', '@bauer', '24/06/1970');

insert into Amigo Values (40, 'Chuck', 'Norris', 7777777, 'cnorris@dios.com', '@DonChuck', '07/07/1940');

End

SE POBLA LA TABLA CERVEZA.

BEGIN

insert into Cerveza values (10, 'Escudo', 'CCU');

insert into Cerveza values (20, 'Pale Ale', 'Kunstmann');

insert into Cerveza values (30, 'Bock', 'Kunstmann');

insert into Cerveza values (40, 'Cristal', 'CCU');

insert into Cerveza values (50, 'Baltica', 'CCU');

insert into Cerveza values (60, 'Heinecken', 'Heinecken');

insert into Cerveza values (70, 'Chimbombo', 'Cuneta');

END

SE POBLA LA TABLA PRUEBA

Begin

insert into prueba values (10, 10, 10);

insert into prueba values (11, 10, 20);

insert into prueba values (12, 10, 30);

insert into prueba values (13, 20, 10);

insert into prueba values (14, 20, 70);

insert into prueba values (15, 30, 40);

insert into prueba values (16, 30, 60);

insert into prueba values (17, 40, 70);

insert into prueba values (18, 40, 20);

END

SE POBLA LA TABLA BAR

BEGIN

insert into bar values (1, 'El Bar de Moe', 'Av. Siempre Viva 278', 'Springfield', 4884665);

insert into bar values (2, 'El Pobre Carlos', 'Av. Balmaceda 2487', 'Talagante', 8154879);

insert into bar values (3, 'Groops!', 'Downtown 200', 'Ciudad de York', 9905674);

insert into bar values (4, 'Atico', 'Santelices 669', 'Isla de Maipo', 8194596);

END

SE POBLA LA TABLA FRECUENTA

BEGIN

insert into frecuenta values (1, 10, 1, 'NOCHE');

insert into frecuenta values (2, 20, 1, 'MAÑANA');

insert into frecuenta values (3, 10, 2, 'NOCHE');

insert into frecuenta values (4, 10, 3, 'TARDE');

insert into frecuenta values (5, 30, 1, 'NOCHE');

insert into frecuenta values (6, 40, 1, 'TARDE');

insert into frecuenta values (7, 40, 3, 'MAÑANA');

insert into frecuenta values (8, 20, 4, 'NOCHE');

insert into frecuenta values (9, 40, 2, 'TARDE');

insert into frecuenta values (10, 30, 2, 'NOCHE');

END

SE POBLA LA TABLA SIRVE

BEGIN

insert into sirve values(30, 1, 10);

insert into sirve values(31, 2, 20);

insert into sirve values(32, 1, 10);

insert into sirve values(33, 2, 20);

insert into sirve values(34, 3, 60);

insert into sirve values(35, 3, 30);

insert into sirve values(36, 3, 20);

insert into sirve values(37, 4, 40);

insert into sirve values(38, 4, 60);

END

SELECT * FROM nombreTabla: DEVUELVE TODOS LOS REGISTROS (DATOS ALMACENADOS EN ATRIBUTOS) DE LA TABLA MENCIONADA

SELECT * FROM AMIGO

SELECT * FROM CERVEZA

SELECT * FROM PRUEBA

SELECT * FROM BAR

SELECT * FROM FRECUENTA

SELECT * FROM SIRVE

EN ESTA CONSULTA, SE ABREN LAS TABLAS AMIGO, CERVEZA Y PRUEBA, DONDE SE LE ASIGNAN ALIAS A, C Y P. SE DEVOLVERA SOLO EL NOMBRE Y EL APELLIDO DEL AMIGO. PRIMERO SE HACE EL JOIN, DONDE SE IGUALAN LAS ID DE UNA TABLA CON EL ID DE LA TABLA INTERMEDIA (EJ: IDAMIGO DE LA TABLA AMIGO CON IDAMIGO DE LA TABLA PRUEBA) . Y FINALMENTE SE ESCRIBE LA CONDICION. ESTA DICE QUE DEVUELVA EL NOMBRE Y APELLIDO DE LOS QUE HAN CONSUMIDO ESCUDO Y ADEMAS BOCK (SE HACE UNA INSTRUCCION ESPECIAL CON IN DONDE SOLO SE UTILIZA EL IDAMIGO PARA SABER LA SEGUNDA CERVEZA QUE BEBIO Y VOLVER A VERIFICAR).

SELECT A.NOMBRE, A.APELLIDO

FROM AMIGO A, CERVEZA C, PRUEBA P

WHERE A.IDAMIGO = P.IDAMIGO

      AND P.IDCERVEZA = C.IDCERVEZA

      AND C.NOMBRE = 'Escudo'

      AND A.IDAMIGO IN

      ( SELECT IDAMIGO

        FROM PRUEBA P, CERVEZA C

        WHERE C.IDCERVEZA = P.IDCERVEZA

              AND C.NOMBRE = 'Bock'

      );

VISTA: ESTA LINEA CREA UNA VISTA PARA SER OCUPADA DESPUES Y VER CAMBIOS. TAMBIEN PUEDE SER LLAMADA COMO SELECT * FROM VISTA SIEMPRE Y CUANDO SE HAYA COLOCADO ARRIBA EN UNA CONSULTA DEFINIDA.

CREATE VIEW VISTA

ESTA CONSULTA DICE QUE OCUPARA LAS TABLAS AMIGO, BAR, FRECUENTA, CERVEZA Y SIRVE. SOLO DEVOLVERA EL NOMBRE DEL AMIGO, NOMBRE DE LA CERVEZA, NOMBRE DEL BAR Y EL HORARIO (SIN CONDICION, VALIDACION O FILTRACION). SE HACEN LOS JOIN.

SELECT A.NOMBRE, C.NOMBRE, B.NOMBRE, HORARIO

FROM AMIGO A, BAR B, FRECUENTA F, CERVEZA C, SIRVE S

WHERE A.IDAMIGO = F.IDAMIGO

  AND F.IDBAR = B.IDBAR

  AND B.IDBAR = S.IDBAR

  AND S.IDCERVEZA = C.IDCERVEZA

 

USER_TABLES MUESTRA TODAS LA INFORMACION DE TODAS LAS TABLAS

SELECT * FROM USER_TABLES

ESTO DESCRIBE LA ESTRUCTURA DE LA TABLA CERVEZA

DESCRIBE CERVEZA

NAMASTE!!!

Como crear un modelo Entidad-Relación

A continuacion, explicare unos sencillos pasos a seguir para crear el modelo con el minimo de errores.

Pasos a seguir:

1) Leer el enunciado y entender hacia que area va dirigida el modelo.
2) Identificar las entidades que tendra el modelo.
3) Identificar los atributos de dichas entidades.
4) Identidicar las relaciones entre las entidades

Tips:

-Las entidades son objetos tangibles e intangibles que posean caracteristicas.
-Buscar en el enunciado los sustantivos que tengan relacion con la entidad.
-Buscar en el enunciado los verbos y que tengan una ceoerencia en la relacion, si el vervo se repite, buscar un sinonimo de dicho verbo.

PD: entre los atributos pueden existir Atributos Explicitos y Atributos Implicitos.
Atributos Explicitos: Estos estan dichos en el enunciado y son pedidos.
Atributos Implicitos: Estos no aparecen ni son pedidos, pero puede caver la posivilidad de que en un futuro se usen.

Top Down ,Bottom Up,

TOP DOWN

También conocida como de arriba-abajo y consiste en establecer una serie de niveles de mayor a menor complejidad (arriba-abajo) que den solución al problema.
Consiste en efectuar una relación entre las etapas de la estructuración de forma que una etapa jerárquica y su inmediato inferior se relacionen mediante entradas y salidas de información.

Este diseño consiste en una serie de descomposiciones sucesivas del problema inicial, que recibe el refinamiento progresivo del repertorio de instrucciones que van a formar parte del programa.
La utilización de la técnica de diseño Top-Down tiene los siguientes objetivos básicos:

• Simplificación del problema y de los subprogramas de cada descomposición.
• Las diferentes partes del problema pueden ser programadas de modo independiente e incluso por diferentes personas.
• El programa final queda estructurado en forma de bloque o módulos lo que hace más sencilla su lectura y mantenimiento.

BOTTOM UP

El diseño ascendente se refiere a la identificación de aquellos procesos que necesitan computarizarse con forme vayan apareciendo, su análisis como sistema y su codificación, o bien, la adquisición de paquetes de software para satisfacer el problema inmediato.

Cuando la programación se realiza internamente y haciendo un enfoque ascendente, es difícil llegar a integrar los subsistemas al grado tal de que el desempeño global, sea fluido. Los problemas de integración entre los subsistemas son sumamente costosos y muchos de ellos no se solucionan hasta que la programación alcanza la fecha límite para la integración total del sistema.

En esta fecha, ya se cuenta con muy poco tiempo, presupuesto o paciencia de los usuarios, como para corregir aquellas delicadas interfaces, que en un principio, se ignoran.

Aunque cada subsistema parece ofrecer lo que se requiere, cuando se contempla al sistema como una entidad global, adolece de ciertas limitaciones por haber tomado un enfoque ascendente.

Uno de ellos es la duplicación de esfuerzos para acceder el software y mas aun al introducir los datos. Otro es, que se introducen al sistema muchos datos carentes de valor. Un tercero y tal vez el mas serio inconveniente del enfoque ascendente, es que los objetivos globales de la organización no fueron considerados y en consecuencia no se satisfacen.

observacion:

cada diseño esta definido para establecer el orden y la necesidad ejemplo para crear una base de datos "Top-Down" lo cual ayuda tambien a que se puedan acortar los procesos y asi lograr un programa mas eficiente o para buscar imperfeciones o el solo hecho de tenerhacer una mejora en el modelo relacional como lo es" Targeted Modeling".

UML (Lenguaje Unificado de Modelado)

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.

Bibliografia: Wikipedia.

Un vistaso a UML

Unified Modeling Language (Lenguaje Unificado de Modelado o LUM) es el lenguaje de modelado de Software mas conocido y esta respaldado por la OMG. UML es un leguaje grafico el cual nos permite visualizar, construir , especificar y documentar sistemas.

Se deve diferenciar que con UML no es posible programar, puesto que es un Lenguaje de Modelamiento, es decir, sirve para mantener al proyecto ordenado y facilitar su comprencion y programacion.

A continuacion mostraremos los 13 tipos de diagramas que nos ofrece UML 2.0



DIAGRAMA DE ESTRUCTURA
se concentra en enfatizar los elementos que deven existir en el modelado:

·Diagrama de Clases: Diagrama de tipo estatico que descrive la esructura de un sistema mostrando sus clases, atributos y relaciones entre ellos. Generalmente el diagrama de Clases es utilizado en el proseso de analisis y deseño del sistema.

·Diagrama de Componentes: Representa como el sistema de un Software es dividido en Componentes y muestra las dependencias entre estos Componentes. Principalmente es utilizado para ver los componentes que pueden entre sistemas o entre diferentes partes de un sistema.


·Diagrama de Objetos: Son utilizados durante el proceso de analisis y Diseño. Este diagrama es muy similar al Diagrama de Clases aunque en estos no se especifican la multiplicidad ni los roles, aunque su notación son muy similares.

·Diagrama de Estructura Compuesta: Es un conjunto de elementos interconectados que colaboran en tiempo de ejecucion para lograr algun propósito. Cada elemento tiene un Rol definido en la colaboracion.

·Diagrama de Despliegue: Los elementos por este tipo de diagramas son nodos (representados como un prisma), componentes (representados por una caja rectangular con 2 protuberancias al lado izquierdo) y asociaciones.

·Diagrama de Paquetes: Muestra como un sistema esta dividido en agrupaciones lógicas mostrando la dependencias entre esas agrupaciones. Dado que esta pensado como un directorio, estos diagramas suministran una descompocicion de jerarquía lógica de un sistema.


DIAGRAMA DE COMPORTAMIENTO
enfatiza lo que deve suceder en el sistema de modelado:

·Diagrama de Actividades: Representa los flujos de trabajo paso a paso de negocios y operacionales de los componentes de un sistema. Este diagrama muestra el flujo de control General del proyecto.

·Diagrama de Casos de Usos: Son a menudo confundidos con los casos de usos. Mientras que ambos conceptos estan relacionados , los casos de usos son mas detallados que los diagramas de casos de usos.

·Diagrama de Estados: Permite identificar bajo qué argumentos se ejecuta cada uno de los procesos y en qué momento podrían tener una variación. Este diagrama permite visualizar de una forma secuencial de cada uno de los procesos.


DIAGRAMA DE INTERACCIÓN
Son un sub-tipo del Diagrama de Comportamiento que enfatiza en el flujo de control y de datos entre los elementos del sistema del modelado:

·Diagrama de Secuencia: Muestra la interaccion de un conjunto de objetos en una aplicacion a traves del tiempo y se modela para cada caso de uso.

·Diagrama de Comunicacion: Modela las interacciones entre objetos o partes en terminos de mensajes en secuencia. Combina la informacion tomada de los diagramas de clases, secuencias y casos de usos descriviendo tanto la estructura estatica como el comportamiento dinamico del sistema.


·Diagrama de Tiempos: Es una grafica en forma de ondas digitales que muestra la relacion temporal entre varias señales, y como varia cada señal en relacion a las demás. Tambien es conocido como Cronograma.


·Diagrama Global de Interacciones: Es una representacion grafica de una interaccion, se ditinge facilmente del diagrama de secuencia y del de comunicaciones y tiene elementos graficos tomados del diagrama de actividades.

Proceso de vida de un Software

Cuando hablamos del proseso de vida de un Software nos referimos a los procesos que se llevan a cabo desde su creacion, hasta cuando es periodicamente mantenido.

Entre los Procesos de vida, podemos encontrar las siguientes estapas:

Requerimientos: Es la estapa en la cual se miden los requisitos nesesarios para que el Software corra, se deve de intentar que sean adecuados. Generalmente aqui es donde se ve si el proyecto puede ser facilmente comercializado o no, puesto que si los requisitos son muy altos, muy pocos lo implementaran, lo cual puede llevar a perdidas de dinero. Si se bajaron mucho los requisitos, el Software puede resultar mediocre y pocos lo usarian, por ende deve de intentarse mantener un equilibrio.

Diseño: En esta etapa se ve como va a ser construido el Software aqui se suele implementar el Modelamiento (Tanto un Modelamiento de la interfaz Grafica, como el Modelamiento de Datos), esta etapa es importante puesto que se deve de tratar con las alternativas para mejorar el Software.

Construcción: Aqui es donde se crean las B.D. y la Interfaz Grafica de Software, generalmente esta es una de las etapas mas largas, puesto que puede tomar meses o años que el Software quede completamente funcional y sin errores.

Pruebas: Generalmente se puede clasificar en 2 tipos de pruebas: verciones Betas cerradas y verciones Betas abiertas.

-Vercion Beta Cerrada: aqui el Software es usado por un numero limitado de usuarios, los cuales al usarlo podran detectar problemas que al momento de construir no fueron notados.

-Vercion Beta Abierta: generalmente se produce despues de la Vercion Beta Cerrada y es para todo publico, aqui se suele probar problemas de conexion entre Servidor y Usuario.

Implementación: Puede ser de manera Pasiva generalmente llamada "Marcha Blanca" o de forma Agresiva, entrando directamente al mercado.

Mantención: Es la etapa mas larga puesto que dura asta que el Software sea dado de baja, aqui se deven de arreglar los diversos problemas que puedan salir con el tiempo, para ello se van sacando "Updates" o Actualizaciones, las cuales pueden tanto arreglar un problema como generar otros, un buen Software deve sacar constantemente Updates puesto que si deja de hacerlo, generalmente es software es dejado de lado por uno mejor. Tambien se deve intentar gastar lo menos posible en este proseso puesto que si es muy caro en un largo periodo puede significar grandes perdidas.

A continuacion, un grafico que muestra la relacion entre Dinero y Tiempo en la vida de un Software:

LOS PROCESOS DE ABSTRACCIÓN

LOS PROCESOS DE ABSTRACCIÓN
Tal como lo dice del libro de Ramón Ruiz Limón son parte de la "Historia y evolución del pensamiento científico".
¿En que consiste el proceso de abstracción?
"En el proceso de abstracción, el pensamiento no se limita a destacar y aislar alguna propiedad y relación del objeto asequibles a Ios sentidos..., sino que trata de descubrir el nexo oculto e inasequible al conocimiento empírico."
Para llevar a cabo este proceso de abstracción es necesario pensar en forma dialéctica, ya que el pensamiento debe aprehender un mundo en continuo movimiento en el que la contradicción es el motor que impulsa el desarrollo de los procesos y objetos de la naturaleza y la sociedad. La esencia, la estructura de las cosas no se revela en forma directa e inmediata, "la cosa misma - señala Kosík - no se manifiesta directamente al hombre. Para captarla se requiere no sólo hacer un esfuerzo, sino también dar un rodeo."
El punto de partida del proceso de abstracción, de la formación de conceptos, categorías, es la realidad tal como se presenta a los órganos sensoriales (concreto sensorial), pero esa realidad está plagada de apariencias, de pseudoconcreciones, entonces no puede ser un concreto real, sino aparente. Recuérdese lo que decía Marx: "Toda ciencia estaría de mas, si la forma de manifestarse las cosas y la esencia de éstas coincidiesen directamente". El concreto real sólo es posible descubrirlo por medio del pensamiento, cuando marche en busca de la abstracción inicial determinante, separando como si fuera telarañas, lo fenoménico o ilusorio de los procesos y objetos en estudio.
Hecho esto, la siguiente operación mental en el proceso de abstracción consiste en construir el concreto de pensamiento (pensamiento abstracto o concreto mental), con la ayuda del análisis y la síntesis. Esto significa elevarse de los concreto a lo abstracto. "Precisamente en el proceso de esta elevación, el pensamiento reproduce el objeto en su integridad."
Esta "separación" permitirá aprehender mejor los procesos que se estudian ya que el pensamiento, a través del análisis y la síntesis, eliminará los aspectos y relaciones no esenciales o secundarias que encubren las características y relaciones básicas de los procesos, a fin de poder establecer explicaciones científicas sobre los mismos.
En el proceso de abstracción, el análisis implica ir de lo concreto a lo abstracto. Por medio de él se desarticula el todo (determinada realidad: una estructura, la social, por ejemplo; un proceso o conjunto de procesos) en cada una de sus partes y relaciones para analizarlas en forma más completa y profunda con el propósito de destacar aquellos aspectos, elementos y relaciones más importantes para la construcción del conocimiento científico.
La síntesis permite reconstruir en el pensamiento el todo de acuerdo con ciertas elaboraciones mentales a fin de comprender mejor las características, elementos y nexos esenciales de Ios procesos y objetos. Esto implica ir de lo abstracto a lo concreto con el propósito de aprehender el objeto de estudio en sus múltiples determinaciones (aspectos, relaciones, nexos).
Si se parte de que el conocimiento se inicia, en un primer momento, con el contacto de los órganos sensoriales con el mundo externo y de aquí surge la materia prima para las elaboraciones conceptuales, las que serán a su vez contrastadas con la realidad concreta a través de la practica científica, puede observarse en este proceso la vinculación de los cuatro métodos descritos anteriormente.
El contacto con la realidad a través de diversos métodos y técnicas como la observación, la entrevista y la encuesta permite obtener datos empíricos para iniciar el conocimiento de las partes e interrelaciones de los objetos y procesos (análisis). Este contacto se realiza con base en una idea, un concepto o hipótesis previos (síntesis) logrados en análisis anteriores. Estas hipótesis de trabajo son una guía preliminar que orienta el análisis a fin de buscar aquellos hechos y relaciones empíricos relevantes para construir hipótesis más consistentes y precisas. Los resultados del análisis se concretan en síntesis parciales que hacen referencia a los conocimientos empíricos recabados.
A partir de estas síntesis y mediante un proceso de inducción se establecen generalizaciones más ricas de contenido en comparación con las hipótesis de trabajo que sirvieron de base para el estudio. La nueva síntesis (hipótesis) se ha obtenido a través de una generalización de hechos particulares, pero también se ha esforzado con el conocimiento existente en los marcos de la ciencia respectiva. Quedarnos con las hipótesis o leyes como si fueran verdades definitivas implicaría caer en el terreno de la metafísica.
Partimos de que la realidad es un proceso y por tanto todo conocimiento respecto a ella es también un proceso que va de síntesis menos compleja a otras más complejas. Pero estas síntesis aun cuando sean complejas y se encuentren ampliamente fundamentadas, tienen que ser contrastadas con la realidad empírica a través de un proceso deductivo que permite derivar consecuencias que sean verificables en forma directa o indirecta, mediata o inmediata.^{80
Realizar análisis sin apoyarnos en síntesis (hipótesis, leyes y teorías) nos limita en la comprensión amplia y profunda de los procesos del universo. A la vez, llevar a cabo síntesis a partir de otras síntesis sin recurrir al análisis puede conducir a conclusiones incorrectas o absurdas. Igualmente, la inducción tiene que rebasar los hechos particulares de los que se parte y establecer afirmaciones de carácter general ya que la ciencia no se agota con la observación y medición de los hechos empíricos. Asimismo, esas generalizaciones (hipótesis, leyes y teorías) sirven de guía para explicar el comportamiento de fenómenos concretos y orientar otras investigaciones empíricas mediante la deducción de consecuencias particulares. El proceso de abstracción en la construcción del conocimiento.
En Resumen: A mi parecer, los procesos de abstraccion, esta basado en analogias, análisis y síntesis de problemas determinados. Buscando la mayor inforcimacion posible acerca de pasos a llevar, datos de usuarios (encuestas) para asi llegar a una solucion concreta.
Bibliografia:
"Historia y evolución del pensamiento científico" Ramón Ruiz Limón.
http://www.eumed.net/libros/2007a/257/indice.htm}

SCRUM

Si bien diferentes opiniones son aceptadas, y supongo que ya habrá quien critique la falta de justificación con modelos matemáticos y otros que elogiarán la flexibilidad las Metodologías de Ágiles, hace ya un par de años que han modificado el mapa del Desarrollo de Software no sin antes hacer ruido.
Obviamente, y quiero hacer la aclaración de ante mano, no es que de aquí encontremos el camino al "Santo Grial", si se me permite la metáfora, ya esto lo ha dejado claro Fred Brooks en aquel recordado y ya mitico artìculo "No Silver Bullet" y en su obra cumbre "The Mythical Man-Month", pero si entiendo que merecen ser traídas a cuenta a fin de su analisis y su crítica al menos.
Entre estas metodologías ágiles encontramos a SCRUM, que surgió originalmente como un modelo de desarrollo de productos tecnológicos, pero Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993, y si bien goza de una popularidad menor a XP (Extreme Programming) es una opcion sustentable a la hora de gestionar un proyecto.

¿Qué es SCRUM?
En la última frase del párrafo anterior radica la clave para entender a SCRUM. No podemos encuadrarlo como una Metodología de Análisis y/o Diseño como puede ser UML o RUP, sino que es una forma de gestionar el trabajo. Se parte de la premisa de la imprevisibilidad del procesos de Desarrollo de Soft, por lo cual no se asume como algo definido y determinativo, sino como una caja negra, un proceso volátil, que no tiene un comportamiento lineal; de esta forma el proceso de desarrollo por ejemplo puede iniciarse con cualquier actividad, no se sigue una secuencia (análisis, diseño, codificación, etc).

Las Iteraciones
El proceso iterativo se repite en SCRUM, al igual que en UML o XP, por ejemplo. Una iteración en Scrum es denominada SPRINT y, por lo general, dura entre 15 días y un mes. Para comenzar cada SPRINT se define una lista de requerimientos o BackLog, los cuales deben estar satisfechos al fin de la iteración.
Hay ocasiones en las que se puede optar por Sprints más largos al comienzo (mes y medio o dos meses) ya que al principio cuesta más obtener un ejecutable y al final Sprints más cortos (una semana o dos) cuando se está en la fase final de refinamiento. Pero básicamente el proceso es el mismo de principio a fin.

BackLog de Producto, BackLog de Versión y BackLog de Sprint
El BackLog de Sprint es solo una de las ramificaciones que podemos encontrar. En un proceso SCRUM podemos distinguir 3 tipos diferentes de BackLog:
El Product Backlog: es la lista de requerimientos del producto, cuando se encuentre completados el producto estará listo. A diferencia de otras metodologías se encuentra siempre en crecimiento y evolución, no se lo da por completado tempranamente, a fin de poder adaptarlo con el avance del proyecto. Retornamos a la premisa de la adaptabilidad.
El Release Backlog o Backlog de Versión: es un extracto del Product Backlog con las prioridades ordenadas segun su necesidad y urgencia para la próxima versión (release). Se especifican con un mayor detalle que los requerimientos del product backlog.
El Sprint Backlog: reúne aquellos requerimientos que se completaran durante el sprint. Al decir completar debe entenderse: codificar, testear y documentar. Si bien originalmente el BackLog de Sprint debía permanecer inmutable, hay otras posturas que sostienen que se puede decidir agregar o quitar tareas según vaya adelantado o atrasado el proceso (flexibilidad).

Los Roles en SCRUM
A primera vista podemos distinguir tres roles fundamentales:
Product Owner (Dueño del Producto): es quien esta mas interesado en los requerimientos funcionales del proyecto (Product Backlog), será quien lidere el desarrollo y el encargado de tratar con el cliente. Es el responsable del proyecto y de una etapa fundamental en SCRUM: la planificación.
Scrum Master: es quien hace de nexo entre el Product Owner y el Equipo. Es básicamente un moderador, encargado de asegurar la cooperación y el cumplimiento de la planificación funcional realizada por el Product Owner. No es necesariamente el líder del equipo, aunque es recomendable que tenga esta distinción a fin de facilitar su trabajo y que sus responsabilidades vayan acompañadas de una apropiada autoridad. Es el encargado de prevenir conflictos y de sacar el mejor provecho de cada integrante del equipo en las reuniones diarias.
El Equipo:debe tener entre 5 y 9 miembros (7 es lo teoricamente ideal) es el conjunto de personas, los encargados de efectivizar la resolución de cada sprint y especificar los resultados del trabajo. Estan autorizados a llevar a cabo casi cualquier actividad a fin de llevar a cabo el objetivo final de cada sprint. De considerarlo necesario puede fragmentar el Sprint Backlog en sub tareas a fin de facilitar la consecución de las mismas. El equipo posee reuniones diarias de no mas de 15 minutos donde se ponen en comun las tareas realizadas en el ultimo día y las a realizar durante el presente; en el desarrollo de las mismas es de vital importancia el Scrum Master para preguntar a cada miembro del equipo que hizo desde la última reunión, que problemas tuvo y con que tareas continuará.

Etapas de SCRUM
Scrum se compone basicamente de cinco etapas: revisión de planes de release, distribución, revisión y ajustes de estandares de producto, sprint, revisión de sprint y cierre.

La Revisión de Planes de Versión se realiza una vez establecido el Release Backlog y es llevada a cabo por el equipo a fin de evaluar las diferentes factibilidades de los requerimientos y estimaciones.
Los desarrolladores, a continuación realizan los ajustes de los estándares y dejan todo listo para comenzar con la etapa fundamental de SCRUM: los Sprints.
Es durante el sprint que el desarrollo propiamente dicho se efectiviza. Engloba diferentes tareas: codificación, test, documentación y revisiones. No existe una secuencia definida de como encarar las subtareas de cada Sprint.
Posterior al Sprint, se desarrolla una revisión del mismo, donde se evaluan los resultados con respecto al Sprint Backlog. En este punto se pueden hacer modificaciones al product Backlog en caso de detectar algún requerimiento que no haya sido tenido en cuenta desde un primer momento (de ocurrir esto debe tratarse de un requerimiento no funcional). Por último se planifica el proximo Sprint.
El producto queda ahora en la etapa de cierre del release y posterior distribución. Es la última oportunidad para efectuar depuración (debugging) antes de construir el entregable y dar el proceso por finalizado. Una vez más, y teniendo en cuenta la imprevisibilidad del proceso de desarrollo de software y su mencionada volatilidad es imposible establecer en qué momento exacto se llegara a este punto.

Como se dijo en la introducción, mas allá de algunas falsas creencias sobre las metodologías ágiles, no existe un "Santo Grial" que nos provea la salvación, y Scrum no es la excepción que confirme esta regla, pero si puede ser una buena forma de reducir el impacto de los cambios en la consecución de un Proyecto de Software.

Fuentes:
http://www.chuidiang.com/
http://www.ingenierosoftware.com/
http://es.wikipedia.org/

Explicación de lo entendido

El SCRUM es necesariamente importante para poder lograr un trabajo eficaz que provoque el menor impacto posible en perdidas futuras de falla de software para ello es que existen distintos pasos a seguir a fin de crear la secuencia “perfecta” como lo es product backlog (Release Backlog o Backlog de Versión)que da prioridad a los pasos más importantes de product backlog  y Sprint back log que prueba testea “Arma el software” dentro de un gran grupo de trabajo compuesto por el jefe el que tiene la “idea en si” el tipo que organiza la reuniiones a fin de acordar lo que se está llevando a cabo dentro del soft. y los trabajadores “equipo” que son los que colocan la mano de obra .

Modelos de Datos.

Es un lenguaje utilizado para la descripción de una base de datos. Por lo general, un modelo de datos permite describir las estructuras de datos de la base (el tipo de los datos que incluye la base y la forma en que se relacionan), las restricciones de integridad (las condiciones que los datos deben cumplir para reflejar correctamente la realidad deseada) y las operaciones de manipulación de los datos (agregado, borrado, modificación y recuperación de los datos de la base).

En un enfoque más amplio, un modelo de datos permite describir los elementos que intervienen en una realidad o en un problema dado y la forma en que se relacionan dichos elementos entre sí.
Por lo general, un modelo de datos presenta dos sublenguajes: un Lenguaje de Definición de Datos o DDL (Data Definition Language), cuya función es describir, de una forma abstracta, las estructuras de datos y las restricciones de integridad; y un Lenguaje de Manipulación de Datos o DML (Data Manipulation Language), que se orienta a describir las operaciones de manipulación de los datos. A la parte del DML enfocada a la recuperación de datos, se la suele conocer como Lenguaje de Consulta o QL (Query Language).

La clasificación de los modelos de datos se realiza de acuerdo al nivel de abstracción:

○ Modelos de Datos Conceptuales son aquellos que describen las estructuras de datos y restricciones de integridad. Se utilizan durante la etapa de análisis de un problema dado y están orientados a representar los elementos que intervienen y sus relaciones. Un ejemplo claro es el Modelo Entidad - Relación.

○Modelos de Datos Lógicos se centran en las operaciones y se implementan en algún manejador de base de datos. Como Ejemplo tenemos el Modelo Relacional.

○ Modelos de Datos Físicos, que son estructuras de datos a bajo nivel implementadas dentro del propio manejador como Arboles B+, Estructuras de Hash, Etc.

Editado y Extraido de http://definicion.de/modelo-de-datos

Las Bases de Datos y su Importancia

Saludos,

-Soy Camilo Palma y les presento este tema que encontre muy interesante.

Importancia de las Bases de Datos

Las BD son una colección de información de cualquier tipo perteneciente a un mismo contexto y almacenado sistemáticamente para su posterior uso.

En este sentido un tarjetero de recetas, un catalogo de fichas bibliográficas, un archivo de inventario en el archivero de una oficina, los registros de calificaciones escolares de un estudiante, etc. Casi toda colección de información puede convertirse en una base de datos.

Una base de datos computarizada: es una colección de información almacenada de forma organizada en un computador.

Las bases de datos computarizadas ofrecen varias ventajas sobre sus contrapartes de papel y lapiz.

Las bases de datos son necesarias para:

FACILITAR:

- El almacenamiento de grandes cantidades de información.
- La recuperación rápida y flexible de información.
- La organización y reorganización de la información.
- La impresión y distribución de información en varias formas.

Programa de base de datos: Es una herramienta de software para organizar el almacenamiento y la recuperación de esa información.

Las BD se aplican en las industrias, bancos locales y nacionales, compañías manufactureras, empresas e instituciones, redes de bancos, etc.
Desde computadoras personales y en situaciones más complejas donde se requiere que muchos usuarios compartan la información, utilizan computadoras multiusuario ya sea, mainframes, minis o redes.

Bibliografia:

-http//:wikipedia.com
-http//:monografias.com