U2 material didactico-diseño de base de datos

2-3-2015

Material didáctico Apuntes de la materia de Base de

datos – Unidad 2 Diseño de Base de

datos

Ciencias empresariales

MC. Jose Antonio Rosales Barrales UNIVERSIDAD DEL PAPALOAPAN, CAMPUS TUXTEPEC

Bases de datos – Ciencias empresariales

M.C. José Antonio Rosales Barrales Página | 1

2 Diseño de Base de datos Los sistemas de Bases de datos se diseñan para gestionar grandes cantidades de información que no existan aisladas

sino que se encuentren interrelacionadas, y que sin lugar a duda forman parte del funcionamiento diario de la

empresa.

Son muchas las consideraciones a tomar en cuenta al momento de hacer el Diseño de la Base de datos, algunas de

las más importantes son:

La velocidad de acceso

El tipo de información

Facilidad de extraer la información requerida

El tamaño de la información

Facilidad de acceso a la información

El comportamiento del SGBD con cada tipo

de información

Fases del diseño de BD La fase inicial del diseño de la BD es la CARACTERIZACIÓN completa de los requisitos de los hipotéticos usuarios de

la BD, para lo cual se tiene que interactuar directamente con los expertos y usuarios del dominio de los datos y

lograr obtener como resultado de esta fase la especificación de los requisitos de los usuarios.

La fase de diseño conceptual es la siguiente etapa, en la cual el diseñador debe escoger un módulo de datos y

traducir los requisitos de los usuarios para obtener un esquema conceptual de la BD. Los modelos de alto nivel

resultan útiles a los diseñadores de bases de datos al ofrecerles un marco conceptual en el que especifican de

manera sistemática los requisitos de datos de los usuarios de las BD y la manera en que se estructurará la BD para

satisfacer esos requisitos.

El esquema desarrollado en esta fase de diseño conceptual ofrece una visión general detallada de la empresa y

deberá permitir la implementación de la BD. El proceso debe pasar de un modelo de datos abstracto a la

implementación de la BD continúa con dos fases de diseño finales.

En la fase de diseño lógico el diseñador relaciona el esquema conceptual de alto nivel con el modelo de

implementación de datos del sistema de BD que se va a usar.

El diseñador usa el esquema de BD específico para el sistema resultante en la fase de diseño físico posterior, en la

que se especifican las características físicas de la BD (entre ellas están la organización de archivos y las estructuras

de almacenamiento interno)

Es importante destacar que para hacer el diseño de la BD se deben considerar muchos aspectos de la infraestructura

sobre la cual se implementará la BD.

EL DISEÑO DE LA BD IMPLICA PRINCIPALMENTE EL DISEÑO DEL ESQUEMA

CONCEPTUAL DE LA BD



2.1 Arquitectura de los sistemas de BD Una de las principales finalidades de los sistemas de BD es ofrecer a los usuarios una visión abstracta de los datos,

es decir, que el sistema oculte los detalles del modo en que se almacenan y mantienen los datos.

2.1.1 Niveles de abstracción de datos de la arquitectura ANSI/SPARC Desde los años 70 el tema de la estandarización de las BD ha producido cantidad de trabajos de investigación en

diversos grupos. Las dos principales instituciones que han trabajado en la normalización de las BD, y que tienen

estudios transcendentales a nivel práctico en la investigación y desarrollo de los SGBD son el grupo Codasy1 y el

ANSI/SPARC, además de ISO.

La estandarización tiene como objetivo proteger las inversiones y defender la independencia del usuario frente a

los suministradores de SGBD.

La arquitectura de sistemas de bases de datos de tres esquemas fue aprobado por la ANSI/SPARC en 1975 como

ayuda para conseguir la separación entre los programas de aplicación y los datos, el manejo de múltiples vistas por

parte de los usuarios y el uso de un catálogo para almacenar el esquema de la BD.

La arquitectura ANSI/SPARC se divide en tres niveles conocidos como Interno, conceptual y externo, que permiten

simplificar la interacción de los usuarios con el sistema.

1. Nivel interno (físico): Es el nivel más bajo, es el que está más cerca del almacenamiento físico; es decir, es

el que tiene que ver con la forma en que los datos están almacenados físicamente en la base de datos.

2. Nivel conceptual (lógico global): tiene un esquema conceptual que describe la estructura de toda la BD

para la comunidad de usuarios de la empresa u organización, es decir, describe qué datos se almacenan en

la BD y qué relaciones existen entre esos datos. Oculta los detalles físicos de almacenamiento y trabaja con

elementos lógicos como entidades, atributos y relaciones.

Nivel externo o nivel de vistas

Vista 1 Vista 2

Nivel conceptual

Nivel interno o físico

Vista 3

Figura 1 Los tres niveles de abstracción de datos



3. Nivel externo (lógico de usuario o vistas): es el más próximo a los usuarios, tiene que ver con la forma en

que los usuarios individuales ven los datos (Esquemas externo o vistas de usuario). Cada esquema externo

muestra la parte de la BD que interesa a un grupo de usuarios, ocultando el resto de la BD. Una vista no

tiene datos almacenados, sino lo único que almacena es su definición.

Los tres niveles son descripciones de los mismos datos, los únicos datos existentes están en el nivel físico,

almacenados en un dispositivo como un Disco duro.

Ejemplo:

Figura 2 Un ejemplo de los tres niveles

El diseño de la BD implica principalmente el DISEÑO DEL ESQUEMA CONCEPTUAL DE LA BD, el cual se encuentra

en la fase de diseño conceptual, ofreciendo con ello diversidad de vistas distintas para usuarios diversos, pero sólo

existe una vista conceptual que es la representación abstracta de los datos en su totalidad.



2.1.2 Arquitecturas implementadas La arquitectura de los sistemas de bases de datos es influenciada por los avances tecnológicos y depende de la

infraestructura informática en la cual se instalen los componentes del sistema de BD, sin embargo es posible ofrecer

una visión única de esos componentes y de las conexiones existentes entre ellos.

Los sistemas de BD pueden estar centralizados o ser del tipo cliente-servidor, pueden diseñarse sistemas de BD que

aprovechen las ventajas de las arquitecturas de computadoras paralelas, y pueden tenerse BD distribuidas.

(Silberschatz, Korth, & Sudarshan, 2006)

ACTIVIDAD 1. Realizar un resumen, por equipo, de los temas: Cap. 18 Arquitectura de los sistemas de Base de datos, Cap. 18.1 Centralizadas y cliente servidor, 18.3 Sistemas paralelos, 18.4 Sistemas distribuidos. Del libro de (Silberschatz et al., 2006), páginas 445 a 457. (453 a 465, páginas de archivo pdf). Se incluirá en el examen preguntas relevantes sobre el trabajo. Entregar 3 clases posterior a la

asignación. Presentar en clase brevemente sus experiencias de aprendizaje sobre el contenido del trabajo.

Hoy en día la mayor parte de los usuarios de los sistemas de BD no se encuentran en el mismo lugar físico en que

se encuentra el sistema de BD, sino que se conectan a él a través de una red. Las aplicaciones de BD por lo tanto

pueden dividirse en dos o tres capas.

red

red

CLIENTE

SERVIDOR

Usuario

Aplicación

Sistema de BD

Usuario

Cliente de aplicaciones

Servidor de aplicaciones

Sistema de BD

Arquitectura de dos capas Arquitectura de tres capas Figura 3 Arquitecturas de BD



ACTIVIDAD 2. Desarrollen por equipo un glosario con los siguientes conceptos: Capa, ODBC, JDBC, estándar de interfaz, lógica del negocio, objetos de software,

sistemas heredados, escalable, explíquenlas en clase

El concepto abstracto de “capa” define a un grupo de tecnologías que proporcionan uno o más servicios a sus

clientes.

Las aplicaciones de la arquitectura de dos capas se dividen en un componente que reside en la máquina cliente,

que llama a la funcionalidad del sistema de BD en la máquina servidora mediante instrucciones del lenguaje de

consultas (Dos estándares de interfaces de interconexión conocidos son ODBC y JDBC).

En una arquitectura de tres capas, la máquina cliente actúa simplemente como una parte visible al usuario y no

contiene ninguna llamada directa a la base de datos. En vez de eso, el extremo cliente se comunica con un servidor

de aplicaciones, generalmente mediante una interfaz de formularios. El servidor de aplicaciones a su vez, se

comunica con el sistema de BD para tener acceso a los datos. La lógica del negocio de la aplicación se

incorpora en el servidor de aplicaciones, en lugar de estar distribuida entre múltiples clientes. Las aplicaciones de

tres capas son más adecuadas para aplicaciones de gran tamaño y para aplicaciones de Internet.

Los conceptos primordiales de esta arquitectura se han ido actualizando y hoy día es conocida como arquitectura

multicapa, la cual se compone de clientes, recursos, componentes (servicios) y contenedores. Cada capa contiene

servicios, los cuales incluyen objetos de software, sistemas de gestión de base de datos (SGBD o DBMS) o conexiones

con sistemas heredados. Los departamentos de informática de las empresas utilizan la arquitectura

multicapa debido a que es la forma más efectiva de construir aplicaciones flexibles, escalables y que responda a las

expectativas de los usuarios. Esto se debe a que la funcionalidad de la aplicación se divide en componentes

lógicos asociados con una capa. Cada componente es un servicio que se construye y mantiene en forma

independiente de otros servicios. Los servicios se enlazan mediante un protocolo de comunicaciones que

permite al servicio recibir y enviar información desde y hacia otros servicios. Un cliente se preocupa de

enviar una petición de servicio y recibir los resultados del servicio. Con ésta arquitectura multicapa, Los

programadores pueden desarrollar un sistema más rápidamente creando programas cliente que envía peticiones a

los servicios existentes en la arquitectura multicapa. La lógica del negocio se encuentra dentro de los componentes

y el programador puede modificar la lógica del negocio del servicio para reflejar los últimos cambios sin tener que

modificar el programa cliente.

Contenedor

Respuesta

Programa

Cliente

Componente Componente Componente

Recurso Base de datos

Petición

Figura 4 Arquitectura multicapa



ACTIVIDAD 3. Analice en equipo los incisos y explique en un documento las razones por las cuales ustedes como Gerentes administrativos solicitarían al

departamento de informática desarrollar aplicaciones cliente-servidor o aplicaciones multicapa para cada uno de los problemas planteados. La empresa

se encuentra geográficamente distribuida: ¿Cuál tipo de información sería necesario centralizar y cual utilizar una arquitectura multicapa?

a. Las leyes sobre impuestos salariales del país. b. El pago total del salario mensual de la fábrica.

c. Las ventas mensuales de una oficina de ventas por línea de producto. d. Las ventas semanales de una oficina de ventas por representativo de ventas.

Una de las arquitecturas multicapa más comunes se utiliza en aplicaciones empresariales centradas en web, las

cuales utilizan navegadores para interactuar con los recursos informáticos de la empresa. Prácticamente cualquier

aplicación centrada en web necesita tener acceso a la base de datos de la empresa de forma que los clientes puedan

introducir nueva información, recuperar información existente y modificar (si es necesario) la información que la

empresa tiene archivada.

El siguiente fragmento extraído del manual de referencia de J2EE de Jim Keogh (2003), explica enormemente la

importancia de la arquitectura de BD y los cambios más recientes en las tecnologías de BD:

La expectativa de gratificación instantánea aumentó con el crecimiento de internet y la madurez de la

infraestructura de las empresas. Todos los ejecutivos como los clientes demandan acceso instantáneo a la

información en cualquier hora (24/7). Los departamentos de informática de las empresas tuvieron que

crear un esquema para reformar sus redes y sistemas para dar servicio a los miles de personas que

solicitaban acceso de forma simultánea a los recursos corporativos. Para atender estas expectativas, los

técnicos tuvieron que volver a pensar la forma en que se almacena, se tiene acceso y se entrega la

información a los clientes. La atención se centró sobre el modelo de arquitectura tecnológica que se

utilizaba para proporcionar servicios a las computadoras de escritorios remotos.

Muchos departamentos de informática utilizaban un modelo de cliente-servidor de dos capas, en la cual

los programas de escritorio conocidos como clientes solicitaban información a través de la red corporativa

a servidores que ejecutaban software que respondía a las peticiones de los clientes.

Sin embargo esta arquitectura de dos capas depende en gran manera de mantener actualizados el software

de los clientes, cosa tanto difícil de mantener como costosa de desplegar en una gran empresa que cuente

con varias intranets y fuerza de trabajo consistente de empleados de campo y otros usuarios remotos.

Los sistemas multicapa basados en web no exigen la actualización del software cliente cada vez que se

modifica la presentación y la funcionalidad de la aplicación.

Fue necesario renovar la infraestructura. Hubo que abandonar la arquitectura cliente-servidor de dos capas

y construir en su lugar una arquitectura multicapa nueva.

El concepto de arquitectura multicapa ha evolucionado a lo largo de varias décadas en forma similar a la

evolución de los lenguajes de programación. El objetivo fundamental de la arquitectura multicapa es

compartir recursos entre clientes, lo cual es la filosofía fundamental de diseño para desarrollar programas.



2.2 Diseño conceptual En la fase de diseño conceptual es donde se traducen los registros de los usuarios a un esquema conceptual de la

BD usando como base un modelo de datos, el cual es la representación de todo el contenido de la información de

la BD, ofreciendo una visión general detallada de la empresa.

Ejemplo obtenido de (Hansen & Hansen, 1997), página 85.

Claramente cada una de las necesidades de los usuarios puede satisfacerse con un sistema de BD. También es claro

que estos tres usuarios tienen necesidades diferentes. Se detecta claramente que los tipos de datos que los tres

usuarios requieren son muy similares. La tarea entonces durante la obtención de los requisitos y el Diseño

Conceptual es identificar las necesidades básicas de datos y crear los Modelos Conceptuales de los datos que nos

aseguren registrar los datos necesarios y las relaciones entre éstos.

En el esquema conceptual, por ser la visión global de los datos, deberá incluirse la descripción de todos los datos e

interrelaciones entre estos, así como las restricciones de integridad y confidencialidad:

El diseñador revisa el esquema para confirmar que todos los requisitos se satisfacen realmente y no entren en

conflicto entre sí. El diseñador también puede examinar el diseño para eliminar cualquier característica

redundante. En este punto, la atención se centra en describir los datos y las relaciones, más que en especificar

los detalles del almacenamiento físico.

Un esquema conceptual completamente desarrollado también indica los requisitos funcionales de la empresa.

En la especificación de requisitos funcionales los usuarios describen el tipo de operaciones (o transacciones)

que se llevarán a cabo con los datos. Un ejemplo de estas operaciones es modificar o actualizar los datos, buscar

y recuperar los datos concretos y eliminar datos.

El esquema conceptual está escrito con otro lenguaje de definición de datos, el DDL conceptual. Si se va a lograr la

independencia física de los datos entonces las definiciones conceptuales de DDL no deben comprender en absoluto

ninguna consideración de la representación física ni la técnica de acceso, deben ser únicamente definiciones del

contenido de la información.

Por lo tanto en el esquema conceptual no debe haber ninguna referencia para la representación de campos

almacenados, la secuencia de registros almacenados, los índices, los esquemas de dispersión, los apuntadores o

cualquier otro detalle de almacenamiento y acceso. Aunque en la mayoría de los sistemas existentes, el

esquema conceptual es en realidad algo más que una simple unión de todos los esquemas externos individuales

más ciertas restricciones de seguridad e integridad.



Existen modelos de datos que permiten realizar el diseño de la BD y que incluyen perspectivas a tomar en cuenta

en el mismo.

Del esquema conceptual se deriva:

Una colección de esquemas externos que son la cisión que tienen de la BD las distintas aplicaciones y

El esquema interno que es la descripción de los datos de cara a la máquina.

La transformación de unos esquemas en otros se llevan a cabo por el SGBD.

Los modelos de datos conceptuales utilizan conceptos como Entidades, Atributos y Relaciones. Una Entidad

representa un objeto o concepto del mundo real, como un empleado o un proyecto que se describe en la base de

datos, un Atributo representa alguna propiedad de interés que describe a una Entidad, por ejemplo: el nombre o

el salario de un empleado. Una Relación entre dos o más Entidades representa una asociación, por ejemplo, una

relación de trabajo entre un empleado y un proyecto. (Tema de la Unidad 3, Modelo Entidad-Relación)

Figura 5 Esquema de la BD, Entidad y Atributos

ACTIVIDAD 4. De la actividad de la Unidad 1, donde seleccionaron una empresa “X” y evaluaron sus tipos de decisiones, realicen una entrevista general con el o

los encargados, para detectar un problema que sugiera ser solucionado utilizando una BD. Redacte el problema y de él obtenga una tabla donde establezca las entidades y sus atributos, explicando el por qué definen al concepto de esa manera. Entregue el trabajo por computadora, impreso. Ocupe el siguiente

modelo de Tabla:

EMPRESA: xxxxxxx Nombre del elemento Conceptos (Entidad/Atributo) Explicación del elemento



2.3 Independencia de datos. Existen dos clases de independencia de los datos: física y lógica.

Uno de los principales objetivos de las BD es conseguir independencia entre las estructuras lógicas y físicas de los

datos, que tiene como consecuencia la independencia entre datos y aplicaciones, de modo que los cambios en la

estructura física tengan una repercusión mínima en los programas de aplicación y viceversa.

El concepto de independencia es visto por ANSI de la siguiente forma:

“La independencia de los datos es la capacidad de un SGBD para permitir que las referencias a los datos

almacenados, especialmente en los programas y en sus descripciones de los datos, estén aisladas de los

cambios y de los diferentes uso en el entorno de los datos, como pueden ser la forma cómo se

almacenan dichos datos, el modo de compartirlos con otros programas y cómo se reorganizan para

mejorar el rendimiento del sistema de BD.”

La independencia de los datos se define como “La humanidad de las aplicaciones ante cambios de la estructura del

almacenamiento y en la técnicas de acceso” (Date & Faudón, 2001)

La independencia físico/lógica, es el elemento clave de las BD, implica la separación entre el almacenamiento y la

organización lógica de los datos tal como éstos se contemplan por los distintos programas de aplicación que hacen

uso de la BD, como lo que se consigue una doble finalidad:

Mismos datos se presentarán de distintas formas según las necesidades de los usuarios. (Las distintas

aplicaciones requerirán visiones diferentes de los mismos datos)

El almacenamiento de los datos, su estructura lógica y los programas de aplicación serán independientes unos

de otros, de modo que un cambio en uno de ellos no obliga a modificar a los demás (El administrador de la BD

debe tener libertad de cambiar las representaciones físicas de los datos en respuesta a los requerimientos

cambiantes, sin tener que modificar las aplicaciones existentes).

Algunos de estos cambios son:

Cambios en aspectos lógicos

En los campos

A nivel lógico cambios en: el nombre, tamaño, tipo, modo de cálculo, contraseñas, etc.

A nivel externo, pueden producirse cambios en la presentación de los datos.

En los registros

A nivel externo y lógico cambios en: los nombres, introducción de nuevos campos, borrado de los

mismos, alteración del orden en que aparecen los campos de un registro, división de un tipo de registro

en dos, unión de dos tipos de registro en uno, contraseñas, etc.

Cambios en aspectos físicos

El tamaño de los bloques, longitud de los registros almacenados, pasar de registros almacenados de

longitud fija a longitud variable.

Respecto a la organización física, cambios n métodos de direccionamiento, tratamiento de

desbordamientos, inserciones y eliminaciones, ubicación de los conjuntos de datos en diferentes

volúmenes.

Cambios en el tipo de soporte de almacenamiento, tipo de dispositivo, sistema operativo, CPU, distribución

geográfica de los datos físicos.



2.4 Modelos de bases de datos Bajo la estructura (esquema) de las BD se encuentra el modelo de datos. No olvide que un modelo formal es aquel

que tiene una base matemática que permite su implementación posterior, y puede ser validado y medido.

Conceptos de Modelo de datos:

Es el instrumento que se aplica a los datos para obtener el esquema (Adoración, 1999)

Es una colección de herramientas conceptuales para describir los datos, sus relaciones, su semántica y las

restricciones de consistencia. Ofrecen un modo de describir el diseño de las BD en cada uno de los niveles de

abstracción. (Silberschatz et al., 2006)

Es un conjunto de conceptos que permiten describir, a distintos niveles de abstracción, la estructura de una

base de datos (esquema). (Adoración, 1999)

Es una definición lógica, independiente y abstracta de los objetos, operadores y demás que en conjunto

constituyen la máquina abstracta con la que interactúan los usuarios. Los objetos nos permiten modelar el

esquema. Los operadores nos permiten modelar el comportamiento. (Date & Faudón, 2001)

Conjunto de conceptos, reglas y convenciones que nos permiten describir y manipular (consultar y actualizar)

los datos de un cierto mundo real que deseamos almacenar en la base de datos. (Adoración, 1999)

Todo modelo de datos tiene básicamente dos tipos de propiedades:

Estáticas: describen el esquema del Universo del discurso y apenas varían en el tiempo. Se utiliza DDL para

describirlas.

Dinámicas: permiten el paso de un estado a otro, ejecutando operaciones sobre los datos almacenados en la

estructura (instancias); se corresponden con la naturaleza evolutiva del undo real. Para expresar las operaciones

se usa DML.

Se debe tomar en cuenta la distinción existente entre un modelo (lógico) y la implementación de este (físico).

Un modelo de datos es un instrumento que permiten describir la estructura (esquema) de una BD a distintos niveles

de abstracción.

Mundo real

Modelo de datos

Estructuras de

datos (esquema)

Figura 6 Aplicación del modelo de datos al mundo real para obtener un esquema



Figura 7 Clasificación de los modelos de datos

Por su nivel de abstracción, los modelos conceptuales constituyen una interfaz útil entre el informático y los

usuarios finales en las primeras etapas del proceso de diseño de BD. Los modelos convencionales se pueden

considerar como interfaz entre el informático y la computadora, apoyando al diseñador en etapas posteriores del

proceso de diseño.

Los modelos de datos son un instrumento eficaz en el diseño de la BD. Los niveles de abstracción de la arquitectura

ANSI facilitan el diseño de una BD, al proporcionar nuevos instrumentos que ayudan a la estructuración, paso a

paso, del mundo real hasta llegar a la base de datos física.

Figura 8 Transformación del mundo real a la BD física

Modelos lógicos. Representación de los tipos de datos existentes

Modelos externos.

sirven para representar los datos de un usuario particular en las estructuras de un Lenguaje de Programación

Modelos globales. Ayudan a describir los datos para el conjunto de usuarios.

Modelos conceptuales

Se utilizan para elaborar el esquema conceptual. Por ejemplo un usuario final explicando su diiseño a un informático.

Enfocados a describir el mundo real con independencia de la máquina

Son modelos de análisis, no de implementación. No están en un SGBD

Sus conceptos son más cercanos al mundo real (Entidad, atributos, relaciones, etc)Ejemplos de estos modelos: Entidad/Relación, infológico, RM/T, SDM.

Modelos convencionales

Mas dependientes de la máquina. Ejemplo: un informático desarrollando el modelo en una computadora.Son soportados por los SGBD y están orientados a describir los datos a nivel lógico

Sus conceptos son propios de cada SGBD

Ejemplos de estos son: Jerárquico, de red, y Relacional

Diseñador

•Realiza abstracción del mundo real

•Obtiene esquema conceptual que detalle los objetos y asociaciones entre ellos, sus propiedades y limitaciones

Describir las reglas y restricciones semánticas o de

integridad

•Integradas las restricciones de integridad en la BD permite que los datos tengan independencia de las aplicaciones.

El modelo Entidad/Relacion

•Adecuado para hacer la abstracción del mundo real.

•Permite describir la manera adecuada la semántica de esa realidad

•Facilita la labor del diseñador al ayudarle en su comunicación con el usuario.



El modelo E/R consiste en una colección de objetos básicos, denominados entidades y de las relaciones entre ellos.

Una entidad es una cosa u objeto del mundo real que es distinguible entre otros objetos, el modelo E/R se usa

mucho en el diseño de BD.

Los modelos conceptuales y en especial el modelo E/R es la base de las herramientas de ayuda asistida por

computadora (CASE), las cuales proporcionan una importante ayuda en el diseño de BD, al disponer de modelos

semánticos que facilitan el diseño conceptual y realizar las transformaciones al modelo Relacional de los propio de

los productos comerciales más extendidos.

El SGBD no comprende los conceptos del esquema conceptual, por lo que es preciso pasar a una descripción en los

términos propios del SGBD para llegar al mundo de los datos, en el cual éstos se almacenan en la estructura física

previamente descrita.

A continuación se describen de manera general algunos modelos de datos convencionales que han sido

implementados a lo largo de la historia de las BD en los SGBD y los que se proyectan actualmente cubrir las

necesidades emergentes.

2.4.1 Modelo de red En ocasiones se les denomina sistemas CODASYL (Congreso sobre Lenguajes de Sistemas de Datos) por el grupo que

los propuso. EL ejemplo más conocido de estos sistemas es IDMS. Estos sistemas exponen apuntadores ante el

usuario.

Los modelos de datos en red representan las entidades en forma de nodos de un grafo, y las relaciones mediante

los arcos que unen dichos nodos.

Actualmente los sistemas basados en este modelo desde el punto de vista tecnológico se han vuelto obsoletos.

2.4.2 Modelo jerárquico Es un caso particular de los modelos de Red, es de los primeros modelos de datos que surgieron en los SGBD

comerciales. No hay una formalización matemática del modelo y de sus lenguajes, como ha ocurrido con el modelo

relacional actualmente implementado en los SGBD, ni tampoco se ha intentado su estandarización.

En el modelo jerárquico los datos son representados ante el usuario como un conjunto de estructuras de árbol

(jerarquías), y los operadores que se proporcionan para manipular dichas estructuras incluyen apuntadores de

recorrido, es decir, los apuntadores que representan las rutas jerárquicas hacia arriba y hacia abajo de los árboles.

La implementación del modelo en lo productos se lleva a cabo en base a los punteros, que varían según los

productos, e incluso un mismo producto proporcionan distintas organizaciones físicas a fin de que el usuario pueda

conseguir una mayor eficiencia en el diseño físico de la BD. El producto jerárquico más extendido y el único que ha

llegado hasta nuestros días es el IMS (Information Managment System) de IBM con su lenguaje de datos DL/I. Los

productos jerárquicos consiguieron altas ventas en el mercado, sin embargo, actualmente desde el punto de vista

tecnológico, se han vuelto obsoletos.

ACTIVIDAD 5. Con el documento proporcionado por el profesor (Modelos de datos convencionales Wikilibro.pdf), realizar un juego de roles, donde cada

equipo defenderá su modelo y lenguaje histórico de BD.



2.4.3 Modelo relacional Los SGBD que se basan en el modelo de datos relacional, han venido a dominar el mercado de las BD, y la mayor

parte de la investigación sobre BD en los últimos 30 años se ha basado en este modelo Está sólidamente

fundamentado en la lógica y en las matemáticas y por lo tanto ofrece un vehículo ideal para la enseñanza de los

principios de BD.

El modelo relacional usa una colección de tablas para representar tanto los datos como sus relaciones. Cada tabla

tiene varias columnas, y cada columna tiene un nombre único. El modelo relacional es un ejemplo de un modelo

basado en registros. Los modelos basados en registros se denominan así porque la BD se estructura en registros de

formato fijo de varios tipos. Cada tabla contiene registros de un tipo dado. Cada tipo de registro define un número

fijo de campos o atributos. El modelo de datos relacional es el modelo de datos más usado y una gran mayoría de

sistemas de BD actuales se basan en el modelo relacional.

Un modelo relacional es aquel que:

1. Los datos son percibidos por el usuario como tablas.

2. Los operadores disponibles para el usuario son operadores que generan nuevas tablas a partir de las

anteriores.

Se les denomina sistemas relacionales ya que precisamente el término relación es básicamente el término

matemático para TABLA. (Concepto que es diferente en el modelo E/R)

•datos

•relaciones

•registros

Tablas

•con nombre único

•conocidos como atributos

•de un tipo fijo de dato

Columnas•de un tipo dado

•con número fijo de campos

Registros

Figura 9 Modelo relacional



2.4.4 Modelo orientados a objetos El término sistemas de bases de datos orientadas a objetos (SGBO. Sistemas de gestión de BD de objetos) se usa

para hacer referencia a los sistemas de BD que soportan sistemas de tipos orientados a objetos y permiten el acceso

a los datos desde los lenguajes de programación orientados a objetos usando el sistema de tipo nativo del lenguaje.

El modelo de datos orientado a objetos es un modelo de datos que está recibiendo una atención reciente. El modelo

orientado a objetos se puede considerar como una extensión del modelo E/R con los conceptos de encapsulación,

los métodos (funciones) y la identidad de los objetos.

Extiende el modelo de datos relacional ofreciendo un sistema de tipos más rico que incluye tipos de datos complejos

y orientados a objetos. Los SGBO surgen debido a la falta de capacidad semántica del modelo relacional para atender

aplicaciones como las de ingeniería (CASE, CAD/CAM, CIM, CAE, etc) sistemas basados en el conocimiento,

tratamiento de documentos, multimedia y gestión de redes que requieren modelar de forma directa, objetos e

interrelaciones complejas y almacenar información de sus procesos y operaciones sobre los datos.

2.4.5 Semiestructurados Permite la especificación de datos donde los elementos de datos individuales del mismo tipo pueden tener

diferentes conjuntos de atributos. Esto lo diferencia de los modelos de datos orientados a objetos, en que cada

elemento de datos de un tipo particular debe tener el mismo conjunto de atributos. El lenguaje de marcas Extensible

(XML) se emplea mucho para representar datos semiestructurados.

Actividades de clase

ACTIVIDAD 1 .............................................................. 3 ACTIVIDAD 2 .............................................................. 4 ACTIVIDAD 3 .............................................................. 5

ACTIVIDAD 4 .............................................................. 7 ACTIVIDAD 5 ............................................................ 11

Actividades de retroalimentación Mencione y explique los componentes principales de un SGBD

Mencione las 6 cualidades de la información

Redacte un breve análisis comparativo entre el nivel externo y el nivel interno de una arquitectura ANSI/SPARC.

Explique tres funciones que lleva a cabo el Administrador de BD

Describa de manera general las 4 fases del diseño de una BD

Describa las arquitecturas de Sistemas de BD: Centralizadas, Cliente-Servidor, Paralelas. No olvide resaltar los

puntos principales de cada una, los cuales permiten diferenciarlas.

Índice de figuras Figura 1 Los tres niveles de abstracción de datos .......................................................................................................... 2

Figura 2 Un ejemplo de los tres niveles .......................................................................................................................... 3



Figura 3 Arquitecturas de BD .......................................................................................................................................... 4

Figura 4 Arquitectura multicapa ..................................................................................................................................... 5

Figura 5 Esquema de la BD, Entidad y Atributos ............................................................................................................ 8

Figura 6 Aplicación del modelo de datos al mundo real para obtener un esquema................................................... 10

Figura 7 Clasificación de los modelos de datos ............................................................................................................ 11

Figura 8 Transformación del mundo real a la BD física ................................................................................................ 11

Figura 9 Modelo relacional ........................................................................................................................................... 13

Bibliografía

Date, C. J., & Faudón, S. L. M. R. (2001). Introducción a los sistemas de bases de datos (p. 936). Pearson Educación. Retrieved from http://books.google.com.mx/books?id=Vhum351T-K8C

Hansen, G. W., & Hansen, J. V. (1997). Diseño y administración de bases de datos (2nd ed., p. 569). Madrid, España: Prentice Hall.

Silberschatz, A., Korth, H. F., & Sudarshan, S. (2006). Fundamentos de bases de datos (5th ed., p. 944). Madrid, España: Mcgraw-Hill Interamericana.

Contenido 2 Diseño de Base de datos .................................................................................................................................. 1

Fases del diseño de BD............................................................................................................................................ 1

2.1 Arquitectura de los sistemas de BD ...................................................................................................................... 2

2.1.1 Niveles de abstracción de datos de la arquitectura ANSI/SPARC ................................................................. 2

2.1.2 Arquitecturas implementadas ....................................................................................................................... 4

2.2 Diseño conceptual ................................................................................................................................................. 7

2.3 Independencia de datos. ...................................................................................................................................... 9

2.4 Modelos de bases de datos ................................................................................................................................ 10

2.4.1 Modelo de red.............................................................................................................................................. 12

2.4.2 Modelo jerárquico ....................................................................................................................................... 12

2.4.3 Modelo relacional ........................................................................................................................................ 13

2.4.4 Modelo orientados a objetos ...................................................................................................................... 14

2.4.5 Semiestructurados ....................................................................................................................................... 14

Actividades de clase .................................................................................................................................................. 14

Actividades de retroalimentación ............................................................................................................................ 14

Índice de figuras ........................................................................................................................................................ 14

Bibliografía ................................................................................................................................................................ 15

U2 material didactico-diseño de base de datos

Education

Transcript of U2 material didactico-diseño de base de datos