BUSINESS SYSTEM PLANNING

para la planeacin de sistemas de informacin IBM ha desarrollado una metodologa estructurada que se conoce como B.S.P(Business System Planing) o planeacin de sistemas para el negocio. Esta metodologa facilita el establecimiento de un plan de sistema de informacin que satisfaga las necesidades de informacin de corto y largo plazo de cualquier negocio. el B.S.P. provee un plan de desarrollo a travs de los siguientes pasos: 1. un acercamiento top-down (de arriba hacia abajo) para conseguir que la gente se comprometa y se involucre, comenzando desde la alta gerencia hasta los cargos operacionales, y la realizacin de un estudio sobre toda la empresa o negocio, trabajando desde un nivel macro hasta un nivel micro. 2. una implantacin bottom-up(de abajo hacia arriba), es decir desde el nivel operacional hasta el nivel estratgico. 3. el uso de una metodologa estructurada y ya aprobada dentro del medio. CARACTERISTICAS DEL BUSINESS SYSTEM PLANING utiliza un enfoque de lo general a lo particular traduce los objetivos de negocio en objetivos de sistemas de informacin utiliza una serie de actividades ampliamente probadas en muchos ambientes diversos.

la efectividad de la metodologa B.S.P. podra ser atribuida a dos componentes: 1. sus principios y conceptos fundamentales, es decir que sus ideas y la lgica que utiliza es invariable incluyendo los estndares sobre los cuales se basan sus procedimientos. 2. la secuencia de actividades ,tcnicas, disciplinas, tiempo, planeacin, salidas de informacin, formacin de equipos, etc. son establecidas para satisfacer las necesidades de una organizacin y una situacin en particular. ESTRATEGIAS PRINCIPALES DEL BUSINESS SYSTEM PLANNING Responsabilidad fija sobre datos planeacin y control centralizado de sistemas de informacin independencia organizacional de datos posibilidad de compartir recurso, tales como: datos, equipo, medios de comunicacin.

B.S.P. puede ser concebido como un vehculo o proceso para trasladar la estrategia del negocio en estrategia de sistemas de informacin.

OBJETIVOS DEL BUSINESS SYSTEM PLANNING El primer y ms importante objetivo del B.S.P. es proveer un plan de sistemas de informacin que soporte las necesidades de informacin de corto y largo plazo del negocio y que sea consistente con el plan de negocios.

Existen tambin otros objetivos que ayudan a justificar y clarificar sus alcances. son los siguientes: proteger la inversin en sistemas de informacin, mediante el desarrollo de sistemas con un periodo de vida ms largo, basndolos sobre los procesos de negocio que generalmente no son afectados por los cambios organizacionales. enfocar los recursos de proceso de informacin hacia los objetivos del negocio y manejarlos de una forma eficiente y efectiva para alcanzar las metas. incrementar la confianza de la gerencia en el desarrollo de SI que tengan un alto retorno sobre la inversin. Mejorar las relaciones entre SI y los usuarios.

DESCRIPCION DE LAMETODOLOGIA Las claves del xito en la planeacin, desarrollo e implantacin de una arquitectura de informacin que efectivamente brinde apoyo a los objetivos del negocio son: una planeacion top-down y una implantacion bottom-up

Administracin de los datos como un recurso de la empresa Orientacin del estudio hacia los procesos del negocio Utilizacin de una metodologa comprobada y de fcil comprensin

PASOS DE LA METODOLOGIA 1. OBTENER EL COMPROMISO: ningn estudio de B.S.p debe realizarse sin contar con patrocinio de la alta gerencia y de algunos otros ejecutivos comprometidos e involucrados en l. Dentro de la obtencin del compromiso la actividad ms importante es el nombramiento o seleccin del lder del proyecto o estudio, que ser el ejecutivo. 2. PREPARAR EL ESTUDIO: con una preparacin adecuada puede lograses un ahorra de tiempo, evitar las frustraciones y una mejor calidad en el producto final. 3. EMPEZAR EL ESTUDIO: se inicia con una reunin para analizar el negocio. 4. DEFINIR LOS PROCESOS DEL NEGOCIO: todos dentro del grupo de trabajo deben adquirir un conocimiento profundo sobre los procesos del negocio, es por ello que deben dedicar tiempo completo a la identificacin de los mismos y escribir cada una de sus descripciones. 5. DEFINIR LOS DATOS DEL NEGOCIO: la clasificacin y modificaciones durante los proyectos de seguimiento ayudan para que el desarrollo de las bases de datos para el negocio lleven menos tiempo y un mnimo de redundancia. 6. DEFINIR LA ARQUITECTURA DE INFORMACION: involucra la relacin existente entre procesos y clases de datos . 7. ANALIZAR LOS SISTEMAS ACTUALES: la organizacin actual, los procesos de negocio, los sistemas de informacin y los archivos de datos son analizados con el proposito de identificar redundancias, ayudar a clarificar responsabilidades y entender completamente los procesos del negocio. 8. PERSPECTIVA DE LOS EJECUTIVOS: consiste en el conjunto de notas tomadas en las entrevistas, una actualizacin de los datos obtenidos hasta el momento y una nueva interrelacin de los ejecutivos y el grupo de estudio B.S.P. 9. DEFINICION DE HALLAZGOS Y CONCLUSIONES: entre todos los problemas hallados por los ejecutivos existen muchos que no necesiten soporte de SI, estos deben ser identificados y entregados al patrocinador para darle seguimiento mientras que los problemas que necesitan soporte de SI continuarn evalundose en el estudio B.S.P.

10. DEFINICION DE PRIORIDADES: las prioridades son determinadas por medio de la realizacin de una lista de proyectos estableciendo los criterios de evaluacin de cada uno y realizando la cuantificacin de los mismo. 11. REVISION DE LA ADMINISTRACION DE INFORMACION: el propsito de esta etapa es establecer un control para que la arquitectura de informacin pueda ser desarrollada, implantada y operada eficiente y efectivamente y para definir un ambiente donde los datos sean administrados como un recurso de la empresa. 12. RECOMENDACION Y PLAN DE ACCION: el propsito de este paso es ayudar a la administracin en sus decisiones. 13. RESULTADOS: obtener la aprobacin gerencial para que se desarrollen las recomendaciones generadas por el estudio B.S.P.

APLICACION DE LA METODOLOGIA BUSINESS SYSTEM PLANNING DENTRO DE UNA EMPRESA

El resumen de las caractersticas generales de la empresa se presentan a continuacin: ACTIVIDAD: Presentacin de servicio esenciales en los hogares e indispensable en la industria y comercio. El servicio que se presta es insumos en todas las actividades productivas del pas. AREA DE SERVICIO: los departamentos de Guatemala, Sacatepquez y Escuintla. COMPETENCIA: Ninguna NUMERO DE EMPLEADOS: 2000 NUMERO DE CLIENTES: cerca de medio milln RITMO DE CRECIMIENTO DE CLIENTES: 6% anual

VOLUMEN DE OPERACIONES: $200 millones por ao FRECUENCIA DE VISITA AL CLIENTE una vez por mes

RESULTADOS ESPERADOS lograr que los datos se identifiquen como un recurso de la empresa. Asegurar que la empresa se encuentra en la capacidad de lograr el mejor uso posible de la tecnologa de SI existente y de la que pueda ser adquirida. lograr establecer el plan de SI de corto plaza y largo plazo, el cual satisfaga las necesidades de la empresa

Modelo Entidad/Relacin El modelado de datos entidad/relacin (tambin conocido como entidad/vnculo, E/R) es un modelo conceptual basado en una percepcin del mundo real por medio de objetos bsicos llamados entidades y de las relaciones que existen entre stos. El modelo E/R fue creado por Peter Pin-Shan Chen en 1976, sin embargo ha sido modificado y refinado a travs del tiempo. Se desarroll para facilitar el diseo de las bases de datos por medio de la representacin de la estructura lgica de una base de datos. En el modelo E/R existen 3 conceptos bsicos principales: 1) Entidades (sustantivo) Una entidad es una cosa u objeto del mundo real que se puede identificar en forma distintiva. Es algo que existe y puede ser descrito. Las entidades se pueden clasificar como entidades normales (o fuertes) y entidades dbiles. Una entidad dbil es aquella cuya existencia depende de otra entidad, es decir, no puede existir si la otra entidad no existe. Por el contrario, una entidad normal puede existir pos s misma. 2) Atributos o propiedades (adjetivo) Es una caracterstica distintiva de las entidades. Los atributos pueden identificar, relacionar o describir entidades. Para cada atributo hay un conjunto de valores permitidos que son el dominio del atributo. Adems, un atributo se puede caracterizar por pertenecer a alguno de los siguientes tipos: * Simples o compuestos: el atributo puede ser un todo (p.ej. pas) o puede estar compuesto de otros atributos simples (p.ej. direccin). * Clave: nico dentro de algn contexto (p. ej. CURP).

* Monovaluado o multivaluado: Si el atributo especificado hace referencia a un nico valor se considera monovaluado (p.ej. talla), pero si por el contrario puede tener un conjunto de valores es multivaluado. (p.ej. telfono). * Faltante: En caso de que la entidad no tenga un valor para el atributo, que el atributo no exista para la entidad, o que simplemente se desconozca su valor. (p.ej. ltimo_acceso en caso de que no se hayan realizado accesos) * Base o derivados: Un atributo derivado es el que obtiene su valor de otros atributos o entidades relacionados (p.ej. total_venta), un atributo base es el opuesto al derivado. 3) Relaciones o vnculos (verbo) Una relacin es una asociacin entre entidades. Las entidades involucradas en una relacin son participantes en esa relacin, mientras que al nmero de participantes en la relacin se le llama grado del vnculo o relacin. Una relacin es total cuando todo ejemplar de una entidad A se relaciona con al menos un ejemplar de una entidad B, en caso contrario decimos que es una relacin parcial. En base al nmero de instancias participantes en una relacin, pueden existir tres tipos de cardinalidades uno a uno, uno a muchos/muchos a uno o muchos a muchos. Modelo E/R extendido. Con el paso del tiempo se agregaron algunos conceptos a modelo original propuesto por Chen. Algunos de estos nuevos conceptos son especializacin y generalizacin El concepto especializacin se refiere a diferenciar un subgrupo (subclase) de una entidad (superclase) (p.ej. empleado es una especializacin de persona). Un subgrupo de entidades puede tener atributos que no son compartidos con otros subgrupos. Cada atributo del subconjunto generado posee los atributos del atributo del que se deriv y adicionalmente cuenta con atributos propios (herencia de atributos). Por otro lado, el proceso de integracin de subgrupos para obtener un nivel ms alto se llama generalizacin. Diagramas E/R Los diagramas son una forma prctica y visual de representar la estructura lgica de una base de datos. La notacin para realizar diagramas E/R es la siguiente:

Otras notaciones Con el tiempo se han desarrollado otras notaciones que representan los mismos conceptos por medio de diferentes simbologas, algunas son:

NORMALIZACION DE UNA BASE DE DATOS

El proceso de normalizacin de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relacin al modelo relacional. Las bases de datos relacionales se normalizan para:

Evitar la redundancia de los datos. Evitar problemas de actualizacin de los datos en las tablas. Proteger la integridad de los datos.

Las formas normales son aplicadas a las tablas de una base de datos. Decir que una base de datos est en la forma normal N es decir que todas sus tablas estn en la forma normal N.

Diagrama de inclusin de todas las formas normales. En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayora de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd.1 Primera Forma Normal (1FN) Artculo principal: Primera forma normal Una tabla est en Primera Forma Normal si:

Todos los atributos son atmicos. Un atributo es atmico si los elementos del dominio son indivisibles, mnimos.

La tabla contiene una llave primaria nica. La llave primaria no contiene atributos nulos. No debe existir variacin en el nmero de columnas. Los Campos no llave deben identificarse por la llave (Dependencia Funcional) Debe Existir una independencia del orden tanto de las filas como de las columnas, es decir, si los datos cambian de orden no deben cambiar sus significados

Una tabla no puede tener mltiples valores en cada columna. Los datos son atmicos. (Si a cada valor de X le pertenece un valor de Y y viceversa) Esta forma normal elimina los valores repetidos dentro de una BD Segunda Forma Normal (2FN) Artculo principal: Segunda forma normal Dependencia Funcional. Una relacin est en 2FN si est en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales. (Todos los atributos que no son clave principal deben depender nicamente de la clave principal). En otras palabras podramos decir que la segunda forma normal est basada en el concepto de dependencia completamente funcional. Una dependencia funcional es completamente funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es que . Una dependencia funcional es una dependencia parcial si hay algunos atributos que pueden ser eliminados de X y la dependencia todava se mantiene, esto es . Por ejemplo {DNI, ID_PROYECTO} HORAS_TRABAJO (con el DNI de un empleado y el ID de un proyecto sabemos cuntas horas de trabajo por semana trabaja un empleado en dicho proyecto) es completamente dependiente dado que ni DNI HORAS_TRABAJO ni ID_PROYECTO HORAS_TRABAJO mantienen la dependencia. Sin embargo {DNI, ID_PROYECTO} NOMBRE_EMPLEADO es parcialmente dependiente dado que DNI NOMBRE_EMPLEADO mantiene la dependencia. Tercera Forma Normal (3FN) Artculo principal: Tercera forma normal La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos que no son clave. Un ejemplo de este concepto sera que, una dependencia funcional X->Y en un esquema de relacin R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.

Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva va DNUMBER porque las dependencias SSNDNUMBER y DNUMBERDMGRSSN son mantenidas, y DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que DNUMBER no es una clave de EMP_DEPT. Formalmente, un esquema de relacion R est en 3 Forma Normal Elmasri-Navathe,2 si para toda dependencia funcional , se cumple al menos una de las siguientes condiciones: 1. X es superllave o clave. 2. A es atributo primo de R; esto es, si es miembro de alguna clave en R. Adems el esquema debe cumplir necesariamente, con las condiciones de segunda forma normal. Forma normal de Boyce-Codd (FNBC) Artculo principal: Forma normal de Boyce-Codd La tabla se encuentra en FNBC si cada determinante, atributo que determina completamente a otro, es clave candidata. Deber registrarse de forma anillada ante la presencia de un intervalo seguido de una formalizacion perpetua, es decir las variantes creadas, en una tabla no se llegaran a mostrar, si las ya planificadas, dejan de existir. Formalmente, un esquema de relacin R est en FNBC, si y slo si, para toda dependencia funcional vlida en R, se cumple que 1. X es superllave o clave. De esta forma, todo esquema R que cumple FNBC, est adems en 3FN; sin embargo, no todo esquema R que cumple con 3FN, est en FNBC. Cuarta Forma Normal (4FN) Artculo principal: Cuarta forma normal Una tabla se encuentra en 4FN si, y slo si, para cada una de sus dependencias mltiples no funcionales X->->Y, siendo X una super-clave que, X es o una clave candidata o un conjunto de claves primarias. Quinta Forma Normal (5FN) Artculo principal: Quinta forma normal Una tabla se encuentra en 5FN si:

La tabla est en 4FN No existen relaciones de dependencias no triviales que no siguen los criterios de las claves. Una tabla que se encuentra en la 4FN se dice que est en la 5FN si, y

slo si, cada relacin de dependencia se encuentra definida por las claves candidatas. CLAVE PRIMARIA En el diseo de bases de datos relacionales, se llama clave primaria a un campo o a una combinacin de campos que identifica de forma nica a cada fila de una tabla. Una clave primaria comprende de esta manera una columna o conjunto de columnas. No pueden haber dos filas en una tabla que tengan la misma clave primaria. Una clave primaria debe identificar unvocamente a todas las posibles filas de una tabla y no solo a las filas que se encuentran en un momento determinado. Ejemplos de claves primarias son DNI (asociado a una persona) o ISBN (asociado a un libro). Las guias telefnicas y diccionarios no pueden usar nombres o palabras o nmeros del sistema decimal de Dewey como claves candidatas, porque no identifican unvocamente nmeros de telfono o palabras. Una clave primaria es un caso especial de clave nica. La mayor diferencia es que para claves nicas, no se impone automticamente la restriccin implcita NOT NULL, mientras que para claves primarias, s. As, los valores en columnas de clave nica pueden o no ser NULL. Otra diferencia es que las claves primarias deben definirse por medio de otra sintaxis. El modelo relacional, segn se lo expresa mediante clculo relacional y lgebra relacional, no distingue entre clave primaria y otros tipos de claves. Las claves primarias fueron agregadas al estndar SQL principalmente para conveniencia del programador. Tanto claves nicas como claves primarias pueden referenciarse con claves forneas.

CLAVE FORANEA En el contexto de bases de datos relacionales, una clave fornea (o Foreign Key FK) es una limitacin referencial entre dos tablas. La clave fornea identifica una columna o grupo de columnas en una tabla(tabla hija o referendo) que se refiere a una columna o grupo de columnas en otra tabla (tabla maestra o referenciada). Las columnas en la tabla referendo deben ser la clave primaria u otra clave candidata en la tabla referenciada.

Los valores en una fila de las columnas referendo deben existir solo en una fila en la tabla referenciada. As, una fila en la tabla referendo no puede contener valores que no existen en la tabla referenciada. De esta forma, las referencias pueden ser creadas para vincular o relacionar informacin. Esto es una parte esencial de la normalizacin de base de datos. Mltiples filas en la tabla referendo pueden hacer referencia, vincularse o relacionarse a la misma fila en la tabla referenciada. Mayormente esto se ve reflejado en una relacin uno (tabla maestra o referenciada) a muchos (tabla hija o referendo). La tabla referendo y la tabla referenciada pueden ser la misma, esto es, la clave fornea remite o hace referencia a la misma tabla. Esta clave externa es conocida en SQL:2003 como auto-referencia o clave fornea recursiva. Una tabla puede tener mltiples claves forneas y cada una puede tener diferentes tablas referenciadas. Cada clave fornea es forzada independientemente por el sistema de base de datos. Por tanto, las relaciones en cascada entre tablas pueden realizarse usando claves forneas. Configuraciones impropias de las claves forneas o primarias o no forzar esas relaciones son frecuentemente la fuente de muchos problemas para la base de datos o para el modelamiento de los mismos

ATRIBUTOS Los atributos representan caractersticas o propiedades de la entidad relevantes para el sistema a desarrollar, por ejemplo, la cdula 555555, el nombre Pedro Prez, etc. Los atributos se agrupan en clases atributos o conjuntos atributos, teniendo entonces el conjunto atributo cdula, nombre, etc, y esto es lo que se representa en el modelo E-R. Dependiendo del nivel de abstraccin del diagrama E-R la representacin explcita de los atributos es opcional. Un conjunto atributo se representa como un valo enlazado a la clase entidad a la que pertenece. El valo contiene el nombre del atributo, por ejemplo los conjuntos atributos de la clase entidad empleado son:

ENTIDADES Una entidad representa algo que puede identificarse en el ambiente de trabajo del usuario y que es importante para el sistema a desarrollar, por ejemplo el cliente Pedro Prez, el pedido 322345, el producto 877899, etc. Las entidades se agrupan en clases entidades o conjunto entidades del mismo tipo y esto es lo que se representa en el modelo E-R Un conjunto entidad se representa como un rectngulo que contiene el nombre de la entidad, por ejemplo, los conjunto entidad empleado y producto se representan como: Por comodidad muchos autores intercambian los conceptos conjunto entidad y entidad, haciendo referencia en el modelo E-R a entidades, representando en realidad conjuntos entidades.