|
Universidad Aut�noma de Sinaloa
|
||
|
-----------------------------------
El t�rmino mensaje en un contexto orientado a objetos, no implica el uso de un mensaje f�sico en una red de computadoras, si no que se refiere al paso de solicitudes entre objetos sin tener en cuenta detalles espec�ficos de implementaci�n. La capacidad de modificar la definici�n de un objeto sin afectar al resto del sistema est� considerada como una de las mayores ventajas del modelo de programaci�n orientado a objetos.1 Modelado SOM El modelo SOM, o modelado de Objetos como aqu� le llamaremos, permite ilustrar a la base de datos en t�rminos de Objetos de negocio, y no directamente en tablas. bajo la metodolog�a SOM, una entidad es cualquier cosa, concreta o abstracta, con un infinito n�mero de propiedades o caracter�sticas que la describen. Por ejemplo, un auto tiene modelo, n�mero de neum�ticos, tipo de bencina que utiliza, capacidad del tanque de aceite, potencia del motor, peso molecular, capacidad de reflejo de rayos UV seg�n la pintura del fabricante, y as�, podemos tardarnos un buen tiempo describiendo las caracter�sticas del auto. Sin embargo, dependiendo del cliente o usuario al que estemos sirviendo en cuestiones de inform�tica, cada empresa, persona, departamento, instituci�n, compa��a, tendr� necesidades distintas y �nicas en el conjunto de propiedades o caracter�sticas que desean reunir para una entidad en particular. De acuerdo entonces a Kroenke *, al "conjunto nombrado de propiedades que suficientemente describen una entidad en el ambiente de trabajo del usuario", ese es un Objeto Sem�ntico. Algunas ventajas: Algunas desventajas: "Puedo decir que, aun con las desventajas mencionadas, siempre vale la pena usar SOM al menos en el modelado inicial de Base de Datos, para despu�s continuar su mantenimiento en herramientas que incorporen el modelo ER; en estas �ltimas pueden crearse "vistas" o ventanas de la base de datos en donde cada vista sea el conjunto de tablas de un solo Objeto Sem�ntico, y as� poder ver al Sistema en t�rminos de objetos en el resto de su vida �til", dijo Guillermo Najar. MODELO SEM�NTICO Introducci�n El �rea del modelado sem�ntico fue tema de un buen n�mero de investigaciones a finales de la d�cada de 1970 ya principios de la de 1980. La motivaci�n de esas investigaciones (o sea, el problema que trataban de resolver los investigadores) fue la siguiente: los sistemas de bases de datos en general -relacionales o no-- s�lo tienen en realidad una comprensi�n limitada del significado de la informaci�n contenida en la base de datos; Por lo regular "entienden" ciertos valores at�micos sencillos de los datos y quiz� ciertas interrelaciones de muchos a uno entre esos valores, pero casi nada m�s. Y ser�a bueno que los sistemas pudieran comprender un poco m�s, pues as� podr�an responder de manera un poco m�s inteligente a las interacciones con los usuarios. Y quiz� manejar interfaces con el usuario m�s avanzada. El t�rmino modelo sem�ntica de datos, empleado a veces para referirse a uno u otro de los modelos "extendidos", no resulta muy adecuado, porque parece sugerir que el modelo en cuesti�n ha logrado de alguna manera capturar toda la sem�ntica de los datos correspondientes. Por otro lado, "modelado sem�ntico" es un descriptor apropiado para la actividad general de intentar representar el significado. En este cap�tulo presentamos una breve introducci�n a algunas de las ideas fundamentales de esa actividad. Enfoque General Podemos caracterizar el enfoque general del problema del modelado sem�ntico en t�rminos de los siguientes cuatro pasos. 1. Primero, intentamos identificar un conjunto de conceptos sem�nticos que parecen ser �tiles al hablar informalmente del mundo real. 2. Enseguida, tratamos de inventar un conjunto de objetos simb6licos (o sea, formales) correspondientes que puedan emplearse para representar los conceptos sem�nticos anteriores. 3. Tambi�n desarrollamos un conjunto de reglas de integridad formales correspondientes a esos objetos formales. 4. Por �ltimo, tambi�n desarrollamos un conjunto de operadores formales para manipular esos objetos formales. Correspondientes, reuniendo as� todas las propiedades de una cierta entidad. Los objetos, reglas y operadores de estos pasos 2 a 4, constituyen todos juntos un modelo de datos "extendido"; o ser� "extendido" si esas construcciones son en verdad un superconjunto de las de uno de los modelos b�sicos, como el modelo relacional b�sico; pero en realidad no hay una distinci�n clara entre lo que es extendido y lo que es b�sico en este contexto. Advi�rtase, por cierto, que las reglas y los operadores son parte del modelo tanto como lo son los objetos. Pero a pesar de este hecho, los operadores son quiz� menos importantes que los objetos y las reglas de integridad desde el punto de vista del desaf�o de bases de datos; por tanto, en el resto del cap�tulo se presta mayor atenci�n a los objetos Y las reglas que a los operadores en s�, aunque en ocasiones ofreceremos algunos comentarios acerca de estos �ltimos. ------------------------------------- MODELO FUNCIONAL En el modelo funcional, el objetivo de los analistas es el de identificar y analizar las �reas funcionales, funciones y actividades que se realizan para llevar a cabo los objetivos de la empresa. Este tipo de informaci�n constituye el punto de partida para la agrupaci�n adecuada de la informaci�n que se emplear� para construcci�n de los modelos de datos. Las tareas principales para llevar a cabo el an�lisis del modelo funcional son: Identificar y analizar las �reas funcionales Identificar y analizar las funciones de cada �rea funcional Identificar y analizar las actividades de cada funci�n Revisar y analizar el modelo funcional con los ejecutivos de alto nivel El modelo funcional es representado por un documento anal�tico que muestra el conjunto de �reas funcionales de la organizaci�n con sus funciones y actividades el cual se puede representar de formas. La primera forma consta de una tabla que contiene el nombre del �rea funcional con sus funciones y su respectiva actividad por funci�n El Modelo Funcional sirve como base para el an�lisis del Modelo de Datos, porque del Modelo Funcional se extraen datos de acuerdo a las actividades y funciones analizadas con el objetivo de obtener informaci�n de : Las formas y los reportes que se emplean El origen y destino del reporte y documento Las caracter�sticas de su uso Los cat�logos que se emplean en la elaboraci�n del reporte La descripci�n y el formato de cada dato ---------------------------------- ESTRUCTURA DE DATOS RELACIONAL Definici�n: Tipo de base de datos o sistema de administraci�n de bases de datos, que almacena informaci�n en tablas (filas y columnas de datos) y realiza b�squedas utilizando los datos de columnas especificadas de una tabla para encontrar datos adicionales en otra tabla. En una base de datos relacional, las filas representan registros (conjuntos de datos acerca de elementos separados) y las columnas representan campos (atributos particulares de un registro). Al realizar las b�squedas, una base de datos relacional hace coincidir la informaci�n de un campo de una tabla con informaci�n en el campo correspondiente de otra tabla y con ello produce una tercera tabla que combina los datos solicitados de ambas tablas. Por ejemplo, si una tabla contiene los campos Num_mpleado, Apellido, Nombre y Antiguedad (se escribe antig�edad, con dieresis en la u) y otra tabla contiene los campos Departamento, Num_empleado y Salario, una base de datos relacional hace coincidir el campo Num_empleado de las dos tablas para encontrar informaci�n, como por ejemplo los nombres de los empleados que ganan un cierto salario o los departamentos de todos los empleados contratados a partir de un d�a determinado. En otras palabras, una base de datos relacional utiliza los valores coincidentes de dos tablas para relacionar informaci�n de ambas. Por lo general, los productos de bases de datos para microcomputadoras o microordenadores son bases de datos relacionales. Ve�se tambi�n Ordenador o computadora. En ambas tablas se encuentra el campo num_empleado, este se encarga de relacionarlas. El modelo relacional se divide en tres partes, las cuales se ocupan de la estructura, la integridad y la manipulaci�n de los datos, respectivamente. Cada una de las tres partes tiene sus propios t�rminos especiales. Una relaci�n corresponde a lo que hasta ahora hemos llamado en general tabla. Una tupla corresponde a una fila de esa tabla y un atributo a una columna, El n�mero de tuplas se denomina cardinalidad y el n�mero de atributos se llama grado. La clave primaria es un identificador �nico para la tabla; es decir, una columna o combinaci�n de columnas con la siguiente propiedad: nunca existen dos filas de la tabla con el mismo valor en esa columna o combinaci�n de columnas. Un dominio es una colecci�n de valores, de los cuales uno o m�s atributos (columnas) obtienen sus valores reales.1 Ventajas de utilizar un RDBMS: � Compatibilidad y estandarizaci�n. � Fiabilidad. � Garant�a de independencia de los datos. � Existencia de numerosos sistemas comerciales y consiguiente apoyo t�cnico. � Conectividad garantizada con los lenguajes de programaci�n est�ndar. Las desventajas m�s obvias son las siguientes: � Imposibilidad de representar conocimiento en forma de reglas. � Inexistencia de mecanismos de herencia de propiedades. � Falta de poder expresivo. � Dificultad para gestionar datos no at�micos (por ejemplo, los valores estructurados de una estructura de rasgos. � Incompatibilidad entre los tipos de estructuras de datos que se transfieren o inadaptaci�n de impedancia.2 ----------------------------------------- MODELO DE RED Este modelo fue el resultado de estandarizaci�n del comit� CODASYL. Aunque existen algunas bases de datos de red que no siguen las especificaciones CODASYL, en general, una base de datos CODASYL es sin�nimo de base de datos de red. El modelo de red intenta superar las deficiencias del enfoque jer�rquico, permitiendo el tipo de relaciones de muchos a muchos. Una estructura de datos en red, o estructura plex, es muy similar a una estructura jer�rquica, de hecho no es m�s que un s�per conjunto de �sta. Al igual que en la estructura jer�rquica, cada nodo puede tener varios hijos pero, a diferencia de �sta, tambi�n puede tener varios padres. La imagen muestra una disposici�n plex. En esta representaci�n, los nodos C y F tienen dos padres, mientras que los nodos D, E, G y H tienen s�lo uno. El concepto b�sico en el enfoque de red es el conjunto (`set'), definido por el comit� CODASYL. Un conjunto est� constituido por dos tipos de registros que mantienen una relaci�n de muchos a muchos. Para conseguir representar este tipo de relaci�n es necesario que los dos tipos de registros est�n interconectados por medio de un registro conectivo llamado conjunto conectivo. Los conjuntos poseen las siguientes caracter�sticas: � El registro padre se denomina propietario del conjunto, mientras que el registro hijo se denomina miembro. � Un conjunto est� formado en un solo registro propietario y uno o m�s registros miembros. � Una ocurrencia de conjuntos es una colecci�n de registros, uno de ellos es el propietario y los otros los miembros. � Todos los registros propietarios de ocurrencias del mismo tipo de conjunto deben ser del mismo tipo de registro. � El tipo de registro propietario de un tipo de conjunto debe ser distinto de los tipos de los registros miembro. � S�lo se permite que un registro miembro aparezca una vez en las ocurrencias de conjuntos del mismo tipo. � Un registro miembro puede asociarse con m�s de un propietario, es decir, puede pertenecer al mismo tiempo a dos o m�s tipos de conjuntos distintos. Esta situaci�n se puede representar por medio de una estructura Mult. Anillo. � Se pueden definir niveles m�ltiples de jerarqu�as donde un tipo de registro puede ser miembro en un conjunto y al mismo tiempo propietario en otro conjunto diferente. Como ejemplos de DBMSs comerciales basados en el modelo de red cabe citar el DMS 1100 de UNIVAC; el IDMS, de Cullinane; el TOTAL, de Cincom; el EDMS, de Xerox; el PHOLAS, de Philips; el DBOMP, de IBM, y el IDS, de Honeywell. Tanto el modelo jer�rquico de datos como el de red permiten �nicamente operaciones y facilidades de navegaci�n primitivas. Manipulaci�n de datos de red Un lenguaje de manipulaci�n de datos de red consiste en un conjunto de operadores para procesar datos representados en forma de registros y ligas. Como ejemplos de tales operadores podemos mencionar los siguientes: � Un operador para localizar un registro espec�fico, dado un valor de un campo de ese registro. � Un operador para pasar del padre a su primer hijo en alguna liga. � Un operador para pasar de un hijo al siguiente en alguna liga. � Un operador para pasar de un hijo a su padre dentro de alguna liga. � Un operador para crear un registro nuevo. � Un operador para destruir un registro ya existente. � Un operador para poner al d�a un registro ya existente. � Un operador para conectar un registro (bija) ya existente dentro de una liga. � Un operador para desconectar un registro (hijo) ya existente de una liga. � Un operador para desconectar un registro (bija) ya existente de una ocurrencia de un tipo de liga dado y reconectarlo dentro de otro. Y as� sucesivamente. Advi�rtase que (como lo sugiere el ejemplo) tales operadores trabajan todos por lo regular a nivel de registros. como en los modelos de lista invertida y jer�rquico. ---------------------------------- MODELO JER�RQUICO Estructura jer�rquica de datos Una base de datos de tipo jer�rquico utiliza jerarqu�as o �rboles para la representaci�n l�gica de los datos. Los archivos son organizados en jerarqu�as, y normalmente cada uno de ellos se corresponde con una de las entidades de la base de datos. Los �rboles jer�rquicos se representan de forma invertida, con la ra�z hacia arriba y las hojas hacia abajo.1 Una base de datos jer�rquica consiste en una colecci�n de registros que se conectan entre s� por medio de enlaces. Los registros son similares a los expuestos en el modelo de red. Cada registro es una colecci�n de campos (atributos), que contienen un solo valor cada uno de ellos. Un enlace es una asociaci�n o uni�n entre dos registros exclusivamente. Por tanto, este concepto es similar al de enlace para modelos de red.2 Una base de datos jer�rquica se compone de un conjunto ordenado de �rboles, un conjunto ordenado formado por m�ltiples ocurrencias de un solo tipo de �rbol. . Un tipo de �rbol consiste en un solo tipo de registro "ra�z", junto con un conjunto ordenado de cero o m�s tipos de sub�rbol dependientes (de nivel m�s bajo). Un tipo sub�rbol a su vez consiste en un solo tipo de registro junto con un conjunto ordenado de cero o m�s tipos de sub�rbol dependientes, y as� sucesivamente. Por tanto, el tipo de �rbol completo es un arreglo jer�rquico de tipos de registro. La terminolog�a ra�z/padre/hijo (etc�tera) que acabamos de introducir para los tipos se refleja tambi�n en las ocurrencias. Manipulaci�n de los datos en el modelo jer�rquico Un lenguaje para manipulaci6n de datos con estructura jer�rquica se compone de un conjunto de operadores para procesar datos representados en forma de �rboles. Como ejemplos de tales operadores, podemos mencionar los siguientes: � Un operador para localizar un �rbol espec�fico en la base de datos. � Un operador para pasar de uno de estos �rboles al siguiente. � Operadores para pasar de un registro a otro dentro de uno de esos �rboles desplaz�ndose hacia arriba o hacia abajo por los diversos trayectos jer�rquicos. � Operadores para pasar de un registro a otro de acuerdo con la secuencia jer�rquica de la base de datos. � Un operador para insertar un registro nuevo en una posici�n especificada dentro de uno de esos �rboles. � Un operador para eliminar un registro especificado. Integridad de los datos en el modelo jer�rquico El modelo jer�rquico incluye el manejo "autom�tico" de ciertas formas de integridad referencial en virtud de la siguiente regla: No puede existir un hijo sin su padre. Si se elimina un padre determinado, el sistema eliminar� en forma autom�tica todo el sub�rbol cuya ra�z sea ese padre. De manera similar, no es posible insertar un hijo si no existe ya su padre. La estructura Jer�rquica de datos vigila en forma autom�tica el cumplimiento de las siguientes reglas: NULLS NOT ALLOWED (no se permiten nulos) DELETE ... CASCADES (eliminar. .. se propaga) UPDATE ... CASCADES (modificar... se propaga) Estructura: Ejemplo de una base de datos en modelo jer�rquico: A modo de resumen, enumeramos las siguientes caracter�sticas de las bases de datos jer�rquicas: � Los segmentos de un archivo jer�rquico est�n dispuestos en forma de �rbol. � Los segmentos est�n enlazados mediante relaciones uno a muchos. � Cada nodo consta de uno o m�s campos. � Cada ocurrencia de un registro padre pueden tener distinto n�mero de ocurrencias de registros hijos. � Cuando se elimina un registro padre se deben eliminar todos los registros hijos, para lograr integridad de los datos. � Todo registro hijo debe tener un �nico registro padre excepto la ra�z. ----------------------------------- CONCLUCI�N Seg�n el Ingeniero en Sistemas Guillermo Najar Arreola "El Modelado es la etapa en donde identificamos y "dibujamos" los conjuntos de datos que el Usuario requiere en un Sistema de informaci�n. El Dise�o L�gico es la etapa donde transformamos ese modelo en un dise�o relacional (asumiendo que es el m�s utilizado), independiente de la herramienta (DBMS) que vayamos a utilizar. El Dise�o F�sico es aquel en donde especificamos caracter�sticas propias del DBMS elegido, como tipos de dato concretos, par�metros por cada tabla, campo, relaci�n, etc. Y la construcci�n, es en si el proceso de capturar los "metadatos" o datos sobre datos para materializar el dise�o relacional dentro de nuestro DBMS, quiz� usando scripts SQL". Y continua as�: "Generalmente se usa el modelo de Entidad-Relaci�n para el modelado y dise�o l�gico de bases de datos, en donde a trav�s del reconocimiento de entidades d�biles, entidades fuertes, relaciones entre entidades y su sem�ntica vamos armando la red de la base de datos, para despu�s con algunas reglas, llegar en pocos pasos al dise�o l�gico. De hecho las herramientas gr�ficas de dise�o de Base de Datos que conozco, en su mayor�a usan alg�n "sabor" o variante del modelado Entidad-Relaci�n para elaborar el dise�o l�gico.". En mi opini�n el hacer un modelo de una base de datos es una herramienta para poner mas en claro las ideas, sobre las necesidades de la organizaci�n para la cual se este realizando la base de datos. Para un administrador de base de datos es de suma importancia tener en claro cuales ser�n los datos relaciones y restricciones de los datos, antes de empezar su construcci�n, y es bueno contar con herramientas para ello. -------------------------------------------- BIBLIOGRAFIA An�lisis Del Modelo Funcional Alberto Parraguirre monografias.com Base de datos en castellano: Modelo entidad relaci�n Por: Claudio Casares programaci�n.com Base de datos orientados a objetos.Ing. Lourdes Arl�n Campoy Medrano itlp.edu.mx doo - Programaci�n orientado a objetos personales.igu.net.mx e-Innovatech - Curso VFP .: Entidad Relaci�n TestData www.e-innovatech.com Enciclopedia Microsoft� Encarta� 2002. � 1993-2001 Microsoft Corporation. Modelado de Bases de Datos, Orientado a Objetos.Por Guillermo Najar Arreola. www.postgresql.cl Modelo de datos jer�rquico 6.1 Conceptos B�sicos. Ing. Lourdes Arl�n Campoy Medrano itlp.edu.mx Rincon del Vago html.rincondelvago.com |
![]() ![]() |
|
Escuela de Inform�tica UAS
|