miércoles, 23 de marzo de 2016

MODELAMIENTO DE BASE DE DATOS

DEFINICIÓN:

Un modelo de datos es un sistema formal y abstracto que permite describir los datos de acuerdo con reglas y convenios predefinidos o podríamos decir que es un conjunto de concepto que permiten describir, a distintos niveles de abstracción, la estructura de una base de datos. 


TIPOS (MODELOS LÓGICOS BASADOS EN OBJETOS, MODELOS LÓGICOS BASADOS EN REGISTRO, MODELOS FÍSICOS DE DATOS)

MODELOS LÓGICOS BASADOS EN OBJETOS
Los modelos lógicos basados en objetos se usan para describir datos en los niveles lógico y de vistas. Proporcionan capacidades estructurales muy flexibles y permiten que las ligaduras se especifiquen explícitamente.

Los modelos más conocidos son:

Modelo Entidad - Relación (E - R)
Está basado en una percepción del mundo real que consta de una colección de objetos básicos, llamados entidades, y de las relaciones entre estos objetos. Una entidad es una cosa u objeto que es distinguible de otros objetos. Una relación es una asociación entre varias entidades. Se maneja la correspondencia de cardinalidades que expresa el número de entidades que pueden estar relacionadas con una entidad por medio de relaciones.

Ejemplo
Número de cuenta y saldo pueden ser los atributos de la entidad que representa cuentas bancarias.
Nombre, número de documento, dirección y ciudad pueden ser los atributos que representa a los clientes de un banco.

Cada diagrama entidad - relación está compuesto de:
Rectángulos: Representando conjuntos de entidades.
Elipses: Representando atributos.
Rombos: Representando relaciones entre conjuntos de entidades.
Líneas: Vinculando conjuntos de entidades entre si o conjuntos de entidades con relaciones.

Modelo Orientado a Objetos (OO).

Está basado en una colección de objetos. Un objeto contiene valores almacenados en variables ejemplares dentro de este objeto. Contiene fragmentos de código que operan dentro del mismo y a éstos se les llama métodos. La única manera en que pueden acceder a la base de datos es a través del paso de mensajes a otro objeto.
Los objetos que contienen los mismos tipos de valores y los mismos métodos se agrupan en clases. Los objetos acceden a los datos de otros objetos mediante el envío de mensajes.
Modelo De Datos Semántica
Modelo De Datos Funcional


MODELOS LÓGICOS BASADOS EN REGISTROS:
Se utilizan para describir datos en los niveles conceptual y físico. Estos modelos utilizan registros e instancias para representar la realidad, así como las relaciones que existen entre estos registros (ligas) o apuntadores. A diferencia de los modelos de datos basados en objetos, se usan para especificar la estructura lógica global de la base de datos y para proporcionar una descripción a nivel más alto de la implementación.
Los 3 modelos más aceptados son:
1. Modelo relacional:
Se usa una colección de tablas para representar tanto los datos como las relaciones entre ellos. Cada tabla contiene varias columnas, y cada columna tiene un nombre único.
EJEMPLO:
·         Nombre Documento Dirección Ciudad Nro.Cuenta
·         Aguirre 12345678 San Martín 32 Bahía Blanca A-1111
·         Racciatti 22222222 Belgrano 15 Tres Arroyos B-2222
·         Sosa 32324545 Rivadavia 122 Pigüe C-3333
·         Montero 12127777 Rosas 102 Carmen de Patagones D-4444
·         Aguirre 12345678 San Martín 32 Bahía Blanca A-2244
·         Maciel 30012367 9 de Julio 1816 Punta Alta E-5555
·         Echagüe 54120121 25 de Mayo 1810 Coronel Pringles F-6666
·         Racciatti 22222222 Belgrano 15 Tres Arroyos A-2244



 2. Modelo de red:
Este modelo representa los datos mediante colecciones de registros y sus relaciones se representan por medio de ligas o enlaces, los cuales pueden verse como punteros. Los registros se organizan en un conjunto de gráficas arbitrarias.
EJEMPLO:

3. Modelo jerárquico:
Es similar al modelo de red en cuanto a las relaciones y datos, ya que estos se representan por medio de registros y sus ligas. La diferencia radica en que están organizados por conjuntos de árboles en lugar de gráficas arbitrarias.

EJEMPLO:

MODELOS FÍSICOS DE DATOS:

Se usa para describir datos en un nivel más bajo.

Los más conocidos son:

·         Modelo de unificación
·         Modelo de memoria por marcos.

Un esquema de bases de datos se expresa mediante un conjunto de definiciones que se expresa en un lenguaje de definición de datos (LDD). Las instrucciones del LDD se compilan dando lugar a un conjunto de tablas que se almacenan en un archivo especial, el diccionario de datos contiene meta datos que son datos acerca de los datos.
Un lenguaje de manipulación de datos (LMD) es un lenguaje que permite a los usuarios acceder o manipular datos. Hay dos tipos: LMD procedí mentales que requieren que se especifiquen los datos requeridos y como se buscarán, y los LMD no procedí mentales que solo requiere que se especifique que datos se requieren.
El gestor de transacciones es el responsable de asegurar que la base de datos permanezca en un estado consistente a pesar de los fallos del sistema. El gestor de transacciones también se asegura que las transacciones ocurran sin conflictos.




ENLACE SLIDESHARE:

http://es.slideshare.net/pierinamiovarias5/modelamiento-de-base-de-datos-59960751


EDITADO POR :

Ruíz Paredes Madai
Mio Varías Pierina 







miércoles, 9 de marzo de 2016

FASES PARA LA CREACIÓN DE UNA BASE DE DATOS

ANÁLISIS DE REQUERIMIENTOS Y DISEÑO CONCEPTUAL:

Consiste en especificar lo que se requiere que haga el sistema o la aplicación. 
Permite que las personas observen los elementos lógicos separados de los componentes físicos. Después de lo cual se podrá desarrollar un modelo físico eficiente para la situación donde será utilizado.

De allí surgirán:

Entidades
* Abstracciones de un objeto del mundo real. 
* Representación una colección de objetos que tienen propiedades comunes.
* Ejemplo: CLIENTE
Atributos
* Propiedades de una entidad
* Ejemplo: Nombre y apellido, edad, dirección, etc.
Relaciones o Flujo de datos
* Intercambio de información entre entidades 
* Representan datos en movimiento lógicamente relacionados.
* Describen el movimiento de paquetes de datos de una parte del sistema a otra. 
Procesos
* Una actividad, tarea, proceso, función, etc.
* Transforma entradas en salidas
Almacenes
* Colección de datos en reposo.
* Archivo en disco
* datos en un fichero de papel
* Ejemplo: una FACTURA
Terminadores o Entidades Externas.
* Representan objetos con los cuales el sistema se comunica.
* Personas, agrupamientos, organizaciones
* otros sistemas de software o hardware
* Se encuentran por fuera del sistema.

El análisis de requerimientos solicita entendimiento, clasificación, organización, priorización y validación. 
En todo momento debemos considerar los límites del sistema, teniendo en claro cuál es su objetivo primario ¿Qué es lo que queremos que el sistema haga? ¿Qué salidas de información queremos obtener? Sólo de esta manera se podrá diferenciar qué de toda la información recolectada debemos almacenar y cómo deberá ser el diseño que se ajuste a ella.


DISEÑO CONCEPTUAL

Conjunto de actividades que resultan en un esquema conceptual de alto nivel de una base de datos, independiente del software gestor (SGBD), partiendo de especificaciones de requerimientos.
El diseño conceptual de una base de datos suele hacerse empleando un DER.
Las personas encargadas de esta tarea suelen llamarse diseñadores de bases de datos.
El diseño conceptual de una base de datos forma parte del proceso de diseño de la base de datos completa, que incluye el diseño conceptual, diseño lógico y diseño físico de la misma.

Desarrollo del diseño conceptual de una base de datos
El diseño conceptual parte de los requerimientos, resultando en un esquema conceptual de base de datos. El esquema conceptual sirve luego para el diseño lógico de base de datos.


DISEÑO LÓGICO:


En este punto del proyecto, transformamos el esquema de la base de datos (diseño conceptual), en una serie de estructuras lógicas (tablas, campos, claves primarias y ajenas, etc.), que permitirán almacenar los datos de una forma óptima, sin redundancia de datos (que no haya duplicidad de información; que no se repita el mismo dato) y garantizando la integridad referencial: que no se pueda relacionar un dato A con otro dato B, si este último no existe todavía en la base de datos.
El objetivo es definir correctamente los campos y claves de las tablas, y las relaciones entre ellas, para que el sistema gestor de base de datos pueda avisar con un mensaje de error si el usuario está intentando realizar una operación incorrecta sobre la base de datos, y que no corresponde con el diseño del esquema inicial.

EJEMPLO
Una transformación de la entidad ALUMNO a un lenguaje de tablas sería la siguiente:

La entidad ALUMNO se convierte en una tabla ALUMNO. Cada atributo de la entidad ALUMNO se convierte en un campo en la tabla ALUMNO.

DISEÑO FÍSICO:

El diseño físico de la base de datos optimiza el rendimiento a la vez que asegura la integridad de los datos al evitar repeticiones innecesarias de datos. Durante el diseño físico, se transforman las entidades en tablas, las instancias en filas y los atributos en columnas.
Una vez completado el diseño lógico de la base de datos, se pasa al diseño físico. El personal que realiza el diseño debe tomar decisiones que afectan al diseño físico, algunas de las cuales se listan a continuación.
  • Cómo convertir entidades en tablas físicas
  • Qué atributos utilizar para las columnas de las tablas físicas
  • Qué columnas de las tablas deben definirse como claves
  • Qué índices deben definirse en las tablas
  • Qué vistas deben definirse en las tablas
  • Cómo desnormalizar las tablas
  • Cómo resolver relaciones de varios con varios
  • Qué diseños pueden beneficiarse del acceso hash
El diseño físico es el momento en que se abrevian los nombres que se han elegido durante el diseño lógico. Por ejemplo, puede abreviar el nombre de columna que identifica a los empleados, EMPLOYEE_NUMBER, como EMPNO. En DB2 para z/OS, debe abreviar los nombres de columna y los nombres de tabla para ajustarlos a la restricción física de un máximo de 30 bytes para nombres de columna y un máximo de 128 bytes para nombres de tabla.
La tarea de crear el diseño físico es un trabajo que realmente no acaba nunca. Es necesario supervisar continuamente las características de rendimiento e integridad de los datos de la base de datos a medida que pasa el tiempo. Muchos factores necesitan mejoras periódicas en el diseño físico.
DB2 le permite cambiar muchos de los atributos clave del diseño mediante sentencias ALTER SQL. Por ejemplo, suponga que diseña una tabla particionada de modo que almacena datos para 36 meses. Más adelante descubre que necesita ampliar el diseño a datos para 84 meses. Puede añadir o rotar particiones para los 36 meses actuales a fin de acomodar el nuevo diseño.
El resto de esta información incluye información valiosa que puede ayudarle a crear y mejorar el diseño físico de la base de datos. Sin embargo, esta tarea generalmente requiere tener más experiencia en DB2 que la que probablemente tienen la mayoría de los lectores de esta información de nivel introductorio.






ENLACE : 
http://es.slideshare.net/pierinamiovarias5/fases-para-la-creacin-de-una-base-de-datos-59343643

EDITADO POR : 
Ruiz Paredes Madai
Mio Varías Pierina



martes, 8 de marzo de 2016

DISEÑO DE UNA BASE DE DATOS

Un buen diseño de base de datos garantiza su fácil mantenimiento. Los datos se almacenan en tablas y cada tabla contiene datos acerca de un tema, por ejemplo, clientes. Por tanto, cuando se actualiza una parte de los datos concreta, como una dirección, se hace en un solo lugar, pero ese cambio aparece automáticamente en toda la base de datos.

Una base de datos bien diseñada suele contener distintos tipos de consultas que muestran la información necesaria. Una consulta puede mostrar un subconjunto de datos, como todos los clientes de Londres, o combinaciones de datos de tablas diferentes, como la información de pedidos combinada con la información de clientes.


NORMALIZACIÓN – EJEMPLOS

La normalización es el proceso mediante el cual se transforman datos complejos a un conjunto de estructuras de datos más pequeñas, que además de ser más simples y más estables, son más fáciles de mantener. También se puede entender la normalización como una serie de reglas que sirven para ayudar a los diseñadores de bases de datos a desarrollar un esquema que minimice los problemas de lógica.
Otra ventaja de la normalización de base de datos es el consumo de espacio. Una base de datos normalizada ocupa menos espacio en disco que una no normalizada. Hay menos repetición de datos, lo que tiene como consecuencia un mucho menor uso de espacio en disco. El proceso de normalización tiene un nombre y una serie de reglas para cada fase. Esto puede parecer un poco confuso al principio, pero poco a poco se va entendiendo el proceso, así como las razones para hacerlo de esta manera.

Grados de normalización

Primera Forma Normal: La regla de la Primera Forma Normal establece que las columnas repetidas deben eliminarse y colocarse en tablas separadas.
Segunda Forma Normal: La regla de la Segunda Forma Normal establece que todas las dependencias parciales se deben eliminar y separar dentro de sus propias tablas. Una dependencia parcial es un término que describe a aquellos datos que no dependen de la llave primaria de la tabla para identificarlos.
Tercera Forma Normal: Una tabla está normalizada en esta forma si todas las columnas que no son llave son funcionalmente dependientes por completo de la llave primaria y no hay dependencias transitivas. Comentamos anteriormente que una dependencia transitiva es aquella en la cual existen columnas que no son llave que dependen de otras columnas que tampoco son llave.

EJEMPLO:
Los pasos a seguir son:
» Determinar las columnas que son dependientes de otra columna no llave.
» Eliminar esas columnas de la tabla base.
» Crear una segunda tabla con esas columnas y con la columna no llave de la cual son dependientes.

Al observar las tablas que hemos creado, nos damos cuenta que tanto la tabla ARTÍCULOS, como la tabla ARTÍCULOS_ORDENES se encuentran en 3FN. Sin embargo la tabla ÓRDENES no lo está, ya que NOM_CLIENTE y ESTADO son dependientes de ID_CLIENTE, y esta columna no es la llave primaria. Para normalizar esta tabla, moveremos las columnas no llave y la columna llave de la cual dependen dentro de una nueva tabla CLIENTES. Las nuevas tablas CLIENTES y ÓRDENES se muestran a continuación.



INTEGRIDAD – SEGURIDAD Y RENDIMIENTO DE LA BASE DE DATOS

Autenticación.
La fortaleza de la autenticación es uno de los campos de batalla donde muchas implementaciones NoSQL muestran debilidad. Es común encontrar que la las bases de datos NoSQL incorporen credenciales por defecto, o incluso sin autenticación necesaria o deshabilitada (por ejemplo, Redis). En muchos casos se basan en entornos de confianza en lugar de autenticación de usuario. Dependiendo del software siempre será un punto fundamental a chequear.
Integridad de los datos.
Siguiendo una filosofía donde prima la disponibilidad y el rendimiento, se penaliza en la integridad de los datos. Por ello es necesario utilizar frecuentemente mecanismos complementarios ajenos al motor de la base de datos para asegurar la integridad.
Confidencialidad y cifrado en el almacenamiento.
Por lo general, el almacenamiento de los datos se realiza en texto plano y salvo escasas excepciones como por ejemplo Cassandra y su tecnología Transparent data encryption, no se incorporan mecanismos de cifrado integrados. En la mayoría de los casos sigue siendo necesario delegar el cifrado a procesos en la capa de aplicación o del propio sistema de ficheros.
Auditoria de datos
La mayoría de bases de datos NoSQL carecen de mecanismos propios y robustos de auditoría de datos, de gran peso a la hora de detectar posibles ataques mediante la observación de eventos sobre registros concretos tal y como se hace en bases de datos relacionales.
Seguridad en las comunicaciones.
El uso de cifrado y protocolo SSL es habitual en bases de datos relaciones, en cambio en sistemas NoSQL generalmente se encuentra deshabilitado por defecto, es opcional.



MANTENIMIENTO

1. Ejecute un monitoreo contínuo sobre el rendimiento de la base de datos.
2. Lleve a cabo un afinamiento de manera periódica, y siguiendo mejores prácticas.
3. Asegúrese de contar con la configuración adecuada de concurrencia en SQL Server.
4. Asegúrese que el usuario de sistema se encuentre habilitado.

Notas adicionales
Tenga en cuenta que además del afinamiento y monitoreo a la base de datos, usted también deberá considerar las tareas de monitoreo sobre otros aspectos relacionados que interfieren en el funcionamiento adecuado de la base de datos (p.e configuración del dominio si son parte de una configuración en clúster, la red entre sus servidores de base de datos y otros elementos de la arquitectura del sistema como por ejemplo la SAN o el mismo servidor BPM).


ESTIMAR EL TAMAÑO DE UNA BASE DE DATOS


El crecimiento de las bases de datos de Client Security se puede ver afectado por una serie de factores:
  • Número de agentes Client Security implementados
  • Número de exámenes realizados 
  • Tipo de examen realizado
  • Frecuencia de los exámenes
  • Frecuencia de los eventos de brotes








ENLACE SLIDESHARE :

http://es.slideshare.net/pierinamiovarias5/diseo-de-una-base-de-datos-59292326

Editado por :

Ruíz Paredes Madai
Mio Varías Pierina