FUNDAMENTOS DE BASES DE DATOS Las bases de datos se las utiliza en cada momento de nuestra vida diría, desde el supermercado hasta bibliotecas, el teléfono, la televisión, etc. Una base de datos es un una colección compartida de datos, Un Sistema de Gestión de Base de Datos (SGBD) (SGBD) es un sistema software para mantener, administrar, definir, emplear y controlar los datos de la DB. El sistema anterior al de base de datos fue el sistema de archivo de datos, cuyas desventajas son múltiples frente al SGDB. DESVENTAJAS Y LIMITACIONES DEL SISTEMA DE ARCHIVOS: 1. Separación y aislamiento de datos: entre datos: entre los departamentos que se generaban estos archivos de datos. Cada departamento tenía acceso solo a sus propis datos. 2. Duplicación de datos: Ya que al ingresar datos en cada departamento resultaba n datos duplicados con el consecuente uso de recursos duplicado. 3. Dependencias entre los datos: Si se necesita realizar cambios en los datos, pues esa sencilla modificación deberá hacerse en todos los archivos que tengan ese dato. incompatibles: Cada departamento podría tener su propio sistema de 4. Formatos de archivos incompatibles: Cada archivos y si se quisiera cotejar o equiparar, los datos de un archivo no serían compatibles con los datos de otros. 5. Consultas fijas/proliferación de programas de aplicación: Con aplicación: Con la consideración anterior el desarrollo de aplicaciones para cada sistema de archivos es inevitable, esto multiplica por supuesto el gasto en programadores y desarrolladores. SISTEMAS DE BASE DE DATOS Es un sistema que aglomera varios elementos que ayudan a gestionar e interactuar con datos. Este sistema es la solución al antiguo sistema de archivo de datos. Está conformado por los siguientes elementos: 1. LA BASE DE DATOS Como se dijo anteriormente una base de datos es un conjunto de datos compartidos , una colección c olección compartida de datos. Que necesariamente deben gestionarse de alguna manera. Para este fin existe el Sistema de Gestión de Base de Datos (SGBD) (SGBD) que es un software que permite a los usuarios frontend y backend modificar, alterar, cambiar, incluir, restringir, permitir, en una sola palabra, GESTIONAR los datos de esta base de datos. En una base de datos también se considera c onsidera otros elementos como los meta datos, que son los datos de los datos, o sea información particular acerca de los datos mismos. 2. EL SISTEMA DE GESTIÓN DE BASE DE DATOS En esencia el SGBD es un software que interactúa entre los programas de aplicación del usuario y la base de datos. Para todo este trabajo la base de datos usa lenguajes que principalmente son: a) Lenguaje de definición de datos, DDL b) Lenguaje de modificación de datos, DML c) Lenguaje de estructuración de Datos o en inglés las ya conocidas siglas SQL que en inglés significa Structured Query Language, que es un lenguaje de consulta mas generalizado en bases de datos. Además proporciona las siguientes funcionalidades: - Proporciona un acceso controlado a la base de datos o Seguridad o Integridad Control de concurrencia, acceso compartido de datos. o
Recuperación y restauración de datos. o Catálogo accesible a los usuarios 3. PROGRAMA DE APLICACIÓN Es un programa informático (software) que interactúa con la base de datos emitiendo las apropiadas solicitudes (instrucciones SQL) dirigidas al SGBD. Los usuarios interactúan con la base de datos mediante programas de aplicación. LAS VISTAS. Mediante programas programas de aplicación se puede generar vistas de las bases de datos. Entonces cada usuario puede tener su propia configuración de vista de datos, y esta es una gestión del SGBD. Hay dos ventajas principales en el sistema de vistas y estas son: Las vistas proporcionan un nivel de seguridad, cada usuario ve hasta donde puede o debo ver, o modifica lo que puede modificar según permisos otorgados. La personalización de la vista es otro punto importante porque se ajusta a las necesidades del usuario. 4. COMPONENTES DE UN ENTRNO SGBD Todos los componentes de un entorno SGBD giran alrededor de los datos, siendo si endo estos el puente que une las dos partes importantes de ests componentes. Por un lado está la máquina que a su vez está formado por Software y Hardware, y por el otro está el operador que necesita de personas y procedimientos, es decir los procedimientos los realizan las personas. o
Hardware-Software Hardware-Software DATOS Personas-Procedimientos Personas-Procedimientos MAQUINA OPERADOR 5. DISEÑO DE BASES DE DATOS En grandes empresas que requieren potentes bases de datos, se necesita de un personal especializado en una rama nueva del sistema de bases de datos, el diseñador de bases de datos. lógico que es quien analiza las Dentro de esta línea se distinguen dos tipos: El diseñador lógico que relaciones entre datos, identifica los datos, restricciones, necesidades, relaciones entre usuarios, etc, para la base de datos. El otro tipo de el diseñador físico, que es quien decide como hacer materialmente posible el diseño lógico de la base de datos. En una frase se resume como sigue: -
El operador lógico se encarga de el “ que” , mientras el operador físico se encarga del “como” . .
PAPELES EN UN ENTORNO DE BASE DE DATOS En este apartado se analizará los roles que cumple el personal a cargo del diseño, implantación, mantenimiento y uso de la base de datos. El primer actor dentro de este entorno es el: Administrador de datos y administrador de la base de datos. Existe una diferenciación en estos dos nombramientos de personal ye que básicamente el Administrador de datos se encarga de gestionar los recursos de datos, esto es la planificación, desarrollo y mantenimiento de estándares y políticas que deben estar de acuerdo con las necesidades de los altos directivos de la compañía. En cambio El administrador de la base de datos es quien implementa físicamente la base de datos. O sea que el el DBA (administrador de base de datos) datos) tiene una labor más técnica llegando a ser quien implementa físicamente la base de datos. Estos dos roles estáninterconectados estáninterconectados con los diseñadores que estudiaremos a continuación. Diseñadores de bases de datos En grandes empresas que requieren potentes bases de datos, se necesita de un personal especializado en una rama nueva del sistema de bases de datos, el diseñador de bases de datos. Dentro de esta línea lógico que es quien analiza las relaciones entre datos, identifica se distinguen dos tipos: El diseñador lógico que los datos, restricciones, necesidades, relaciones entre usuarios, etc, para la base de datos. El otro tipo
de el diseñador físico, que es quien decide como hacer materialmente posible el diseño lógico de la base de datos. En una frase se resume como sigue: El operador lógico se encarga del “que” , mientras el operador físico se encarga del “como” . . Desarrolladores de aplicaciones Son quienes desarrollan software para que el usuario final de la base de datos, llámese empleado o cliente, pueda interactuar fácilmente con la base de datos, modificándola de la manera que esté previsto hacerlo. Usuarios finales Son quienes manipulan o consultan a las bases de datos, o modifican de una u otra manera la misma. inexpertos que son los usuarios comunes y corrientes que Se distinguen dos tipos de usuarios, los inexpertos que pueden desde ingresar datos mediante sencillos formularios hasta modificar ciertos campos que no estén restringidos. Éstos actúan en el frontend de la base de datos. avanzados que son quienes están calificados para hacer consultas de alto nivel, e Y los usuarios avanzados que incluso escribir programas de aplicación para uso personal. HISTORIA DE LOS SGBD En resumen existen tres generaciones de SGBD, que las detallo a continuación: Primera Generación: Creado en la década de los 60, consistía en un sistema jerárquico que jerárquico que usaba componentes de menor tamaño para formar un componente de mayor tamaño hasta ensamblar el producto final. El sistema se llamó GUAM, en español método generalizado de acceso y actualización. Así mismo, e la misma década de los 60, aparece el IDS, en español, almacenamiento Integrado de datos que dio lugar al concepto de SGBD en red. La CODASYL (conferencia sobre lenguajes de sistemas de datos) formó un grupo de personas llamados DBTG (grupo de trabajo en bases de datos) que emitió especificaciones para la creación de bases de datos. Segunda generación: También llamado base de datos relacional, consiste en tablas que contienen información relacionada entre si por medio de varias reglas. Es el más común de los SGBD, y en la actualidad existen centenares de SGBD relacionales. Tercera generación: Al igual que en la programación, y en base a la complejidad del manejo de datos ha aparcido ñultimament los SGBD orientado a objetos
CAPITULO 2 Niveles de abstracción – Niveles de arquitectura (ANSI – SPARC) NIVEL 1 – NIVEL EXTERNO Es el nivel que representa la vista al usuario común. Describe la parte de la DB que es relevante para cada usuario NIVEL 2 – NIVEL CONCEPTUAL Este novel representa el nexo entre nivel externo e interno. Representa la Vista Comunitaria. Describe qué datos están almacenados en la DB y las relaciones que existen entre dichos datos NIIVEL 3 – NIVEL INTERNO
Representa la parte física de los datos, esto es, donde están almacenados, en qué computador, en cual disco duro. Este nivel describe cómo están almacenados los datos
RELACIONES ENTRE ARQUITECTURAS, ESQUEMAS Y MODELOS ARQUITECTURA ESQUEMA
USUARIO
Elaborada esta clasificación por la ANSI – SPARC, y se refieren a los niveles de abstracción, y se pueden describir los elementos de los datos
Descripción global de la DB
NIVEL EXTERNO Nivel más alto de abstracción, lo que el usuario puede ver de la BD. Muestra solo la parte de la BD que el usuario está autorizado a ver. El sistema puede generar muchas visiones (vistas) de una misma BD. NIVEL CONCEPTUAL Describe qué datos son almacenados en la BD y la relación que existe entre ellos. Este nivel es usado por los DBA para decidir qué información se debe guardar en la BD. Este nivel consta de dos definiciones Definición de Datos Relaciones entre los datos - Tipo de dato - Longitud del Se definen las campo relaciones entre los - De todos los datos para enlazar elementos de la tipos de registros para BD procesamiento de archivos múltiples. NIVEL INTERNO Se describe en detalle la forma como se almacenan los datos en los dispositivos de almacenamiento. Ej. Discos duros.
ESQUEMAS EXTERNOS O SUB ESQUEMAS Corresponden a las diferentes vistas de los datos. Pueden
MODELOS Un modelo una realida característ realizar. E se realiza d Modelo de Represent tiene de la lao llama U
haber varios.
ESQ. CONCEPTUAL Describe las relaciones entidades, atributos y restricciones.
Modelo de Represent comunitair
SGBD
Hay solo uno.
ESQ. INTERNO Descripción completa del modelo interno . Definiciones, registros, métodos, índices, estructuras, etc. Hay solo uno.
Modelo de Represent par que se
INDEPENDENCIA
EL SGBD LAS RELACIONA ENTRE ELLAS. En otra palabras el SGBD comprueba que cada esquema derive del esquema conceptual Se relacionan mediante ASIGNACIÓN
INDEPENDENCIA LÓGICA
EXTERNO - CONCEPTUAL
ESQUEMA EXTERNO (SUBESQUEMAS)
ESQUEMA CONCEPTUAL
Se relaciona mediante INDEPENDENCIA FÍSICA CORRESPONDENCIA CONCEPTUAL - INTERNA
ESQUEMA INTERNO
LENGUAJES DE DATOS También llamado sub lenguaje de datos , está compuesto por dos parte. 1. Lenguaje de definición de datos (DDL) Que definimos como el lenguaje que sirve para especificar el esquema de la base de datos. En específico el DDL se compone de comandos para la definición, modificación y borrado de esquemas de relación (tablas, relaciones, índices). Como un ejemplo, podemos ver que el script que se genera por ejemplo para la creación de tablas, campos, etc, ese corresponde al DDL 2. Lenguaje de manipulación de datos (DML) En cambio el DML, lo definimos como el lenguaje que accede ya directamente a los datos que contienen las estructuras creadas por el DDL. Es decir, ejemplificando lo dicho, si tomamos en cuenta una base de datos de una empresa, que necesite tener los nombres de los empleados, sus CI, y sus sueldos, pues en principio con el DDL definimos que habrá una sola tabla con los campos Nombre, CI y sueldo. Cuando ya está definida ésta estructura, entonces entra en juego el DML, porque ahí es donde empezamos a ingresar los datos en forma de registros de la tabla generada previamente por el DDL. DDL
DML
Define el esquema que tendrá la BD Contiene los metadatos que es información que describe las características de los mismos datos (Tamaño, longitud, etc). El conjunto de tablas y estructuras que conforman la base de datos se denomina Catálogo. Sentencias, scripts, operadores para manipular los daos propiamente dichos. Entre las operaciones de manipulación de datos pueden ser: - Inserción de nuevos datos - Modificación de datos ya almacenados - Extracción de datos almacenados - Borrado de datos
DML PROCEDIMENTALES.- Viene de procedimiento, o sea que con este lenguaje el usuario le dice al sistema qué datos neceita, pero principalmente le indica cuál (cómo) es la forma exacta de extraerlos.
DML NO PROCEDIMENTALES.- En este lenguaje en cambio el usuario solamente le dice es qué datos necesita, sin preocuparse del cómo lo hace el sistema. También los llaman lenguajes declarativos.
LENGUAJES DE CUARTA GENERACIÓN Estos lenguajes se caracterizan por el ahorro de código y por ende la versatilidad que esto implica. Otra diferencia es que los de 3ra. Generación (3GL) son procedimentales mientras que los de 4GL ya son netamente no procedimentales. Los ejemplos más usados de lenguaje de 4GL son SQL y QBE ( query by example). Ventajas: - Mayor rentabilidad - Mayor productividad - Mas y mejores herramientas Los lenguajes de 4GL comprenden: - Lenguajes de presentación como lenguajes de consulta y generadores de informes. - Lenguajes especializados, hojas de cálculo lenguajes de BD - Generadores de aplicaciones, que manipulan datos para construir aplicaciones. - Lenguajes de muy alto nivel que se usan para generar códigos de aplicación. OTROS TIPOS DE LENGUAJES 4GL Generadores de formularios .- Programa interactivo que crea rápidamente disposiciones de introducción y visualización de datos Generadores de informes.- Genera informes a partir de datos que se encuentran en la base de datos. Se diferencia de un lenguaje de consulta porque dl generador de informes tiene mayor control de la forma en que se visualizan los datos. Generadores gráficos.- Manipulan los datos y generan una imagen gráfica interactuando con funciones estadísticas, etc. Generadores de aplicaciones.- Programa que permite producir otros programas para comunicarse con las bases de datos.
CATEGORIAS DE LOS MODELOS DE DATOS BASADO EN Representa los datos tal cual y OBJETOS como se representa en el mundo real. Cada objeto (entidad) es definido por ciertas características que en base de datos se denomina atributos. Los atributos son propiedades que definen una entidad.
BASADO EN REGISTROS
Esta basado en registros fijos de distinto tipo. Cada registro tiene un número fijo de campos y cada campo suele tiene una longitud determinada también.
MODELOS BASADOS EN OBJETOS Modelo entidad – Relación (El que más se usa).- Representa la realidad por medio de entidades reales (objetos que existe, entiéndase por objeto todo ente que existe en la vida real) que se distinguen de otros por sus características. Por ej. Un alumno (objeto) se distingue de otro por su cédula (atributo), su nombre (atributo), su apellido, etc. Modelo Semántico Modelo Funcional Modelo orientado a objetos.- Este modelo amplía el concepto del M. Entidad – Relación, ya que además de los atributos, incluye las acciones que tiene cada entidad, es decir como se comporta. TIPOS DE MODELOS BASADOS EN REGISTROS: 1. Modelo de datos relacional.- Cada registro está representado en una tabla que contiene una cantidad de columnas (en BD llamados campos). La relación se da en coincidencias entre ciertos campos de estas tablas. Este campo coincidente es el que da la relación entre tablas. Sin embargo, este modelo solo funciona para los niveles externo y conceptual, no aplica a nivel físico. 2. Modelo de datos en red.- Tiene una representación más gráfica de las entidades y sus relaciones. Los datos se representan como colecciones de registros, y las relaciones se logran mediante conjuntos. Las relaciones se representan por medio de ligaduras gráficas. Los registros aparecen y son llamados nodos o segmentos, mientras que el conjunto de relaciones aparecen como aristas. Éstas relaciones pueden ser: uno a uno, uno a muchos, muchos a uno y muchos a muchos.
3. Modelo de datos jerárquico.- Es un tipo de modelo en red, sin embargo, difiere en el tipo de relación, ya que al ser jerárquico, tenemos que los segmentos o registros se relacionan de modo uno a muchos con las aristas,
en otras palabras cada nodo o conexión o segmento solo puede tener un padre, o sea relación uno a muchos. FÍSICOS
Describe cómo se almacenan los datos en un medio físico, llámese este disco duro, SSD, etc. Representa información como estructuras de registro, ordenamiento, rutas de acceso. Los modelos físicos más comunes son el modelo unificador y la memoria de marco.
EL MODELADO CONCEPTUAL El esquema conceptual es en realidad el corazón de la base de datos. Es el que da soporte a las vistas externas y se apoya en el esquema interno. Es el nexo entre la entraña de la BD y lo que los usuarios pueden ver de la BD. El esquema interno es la implementación física del esquema conceptual. El esquema conceptual es una representación completa y precisa de los requisitos de la organización, así llamaremos a la empresa o cliente que requiere de nuestros servicios. Sin una precisión del esquema conceptual, no habrá precisión en las vistas de los usuarios y por supuesto no habrá una robustez del esquema físico. El modelado conceptual o diseño conceptual o también llamado MODEL LÓGICO, de la BD es el proceso de construir un modelo de uso de la información dentro de una empresa, que debe ser independiente de los detalles de implementación como SGBD, soft de app etc. En terminología sin embargo, existe una precisión al momento de llamar modelo lógico y modelo conceptual, ya que el primero presupone un conocimiento del SGBD con el que se implementará, mientras que en el segundo es independiente de los detalles de implementación, es decir, solo diseña en base a un análisis profundo de la empresa.
EL MODELO RELACIONAL Historia El Sistema de Gestión de Base de Datos Relacional (SGBDR) representa a la segunda generación de SGBD. En el modelo relacional todos los datos están estructurados en tablas que se relacionan entre si. Cada relación (Tabla) está compuesta por atributos (columnas). Las filas de la tabla se denominan tuplas y contienen unvalor por cad uno de los atributos. TERMINOLOGÍA BÁSICA - Relación.- Es la tabla donde se escriben los datos - Atributos.- Es una columna nominada de una relación. - Dominio.- Es un conjunto de valores permitidos para uno o más atributos. Existen dos tipos de dominio: Implícitos y explícitos. Los implícitos están dados por la definición del atributo, al asignar un tipo de dato, implícitamente está determinado el rango de valores permitido. Por ejemplo si determino que el atrubuto es salario, de tipo monetario con 4 dígitos, está implícito que el valor estará entre 0 y 9999. En cambio, el dominio explícito, implica que le asignamos un rango de valor cuando declaramos el dominio. Por ej. En el atributo sexo doy un rango de valor 1, es decir puedo ingresar un carácter, pero adicionalmente debo restringir el dominio a M (para masculino) o F (para femenino). - Tupla.- Son las filas de la relación (tabla). - Grado.- El grado de una relación es el número de atributos que contiene. Cuando el grado es 1, es decir cuando la tupla es grado 1 se denomina tupla unaria, si es grado 2, binaria, grado 3 terciaria, y si es mayor a 3 se denomina n-aria. - Cardinalidad.- La cardinalidad en una relación es el número de tuplas que tiene. - Base de Datos Relacional.- Es una colección de relaciones normalizadas, en las que cada relación tiene nombre distintivo.
EJERCICIO DE LIBRO GUÍA: BASE DE DATOS EJEMPLO DE HEMEROTECA RELACION MEDIOS ubicacionNo tituloMedio CompositorDirectorMedio 003 Lo que el viento se Margaret Mitchell llevó 003 Bomba fusión Segundo Rosero 001 Mas Bueno que el Margarita Laso pan RELACION UBICACIÓN ubicacionNo 001 002 003 004 005 006
bodegaNo 1 1 1 1 1 1
TABLA DE DOMINIO PERSONA PERSONA Atributo Nombre de Dominio cedula Número de cédula de la persona nombres
Nombres de la persona
apellidos
Apellidos de la persona
dirección
Dirección de la persona
Sexo
Sexo de la persona
telefono
Número de teléfono
provincia Ciudad Estado civil profesion
interpreteMedio Vivien Leigh / Clasck Gable Segundo Rosero Margarita Laso
estanteNo 1 1 1 2 2 2
Significado Conjunto de todos los números de cédula del país Conjunto de todos los posibles nombres de persona Conjunto de todos los posibles apellidos de persona Conjunto de todas las posibles direcciones del Ecuador
Conjunto de todos los posibles números de teléfono del Ecuador Nombre de la Provincia Conjunto de todas las posibles provincias del Ecuador Nombre de la ciudad Conjunto de todas las posibles ciudades del Ecuador Estado civil de la persona Sexo de la persona Nombre de la profesión Posibles profesiones de la persona
RESTRICCIONES DE INTEGRIDAD
tipoMedio DVD CD CD
cartonNo 1 2 3 1 2 3
Definición de dominio Números, 10 dígitos, enteros, rango: 0 9999999999 Caracter, tamaño 30 Carácter, tamaño 30 Carácter, tamaño 60 Carácter, tamaño 1, valor M oF Numero, 12 digitos, enteos, rango 0 - 999999999999 Carácter, tamaño 30 Carácter, tamaño 30 Carácter, tamaño 30 Carácter, tamaño 30
Son restricciones que permiten normalizar las relaciones, para evitar conflictos u otros errores. Un modelo de datos tiene 2 partes: 1- Parte manipulaiva.- Define los tipos de operaciones permitidas 2- Conjunto de restricciones de integridad..- Garantiza que los datos sean precisos. DEFINICIONES Valores nulos Llamamos así a aquellos datos que no tienen un valor definido o su valor es desconocido. Para evitar conflictos con casilleros vacíos o mejor expresado con relaciones y/o atributos vacíos, se le asigna un valor nulo o null. Integridad de entidad En una relación base ningún atributo de una clave principal puede ser NULL . Una conocida regla de integridad es la llamada Integridad de dominio determinada en las tablas de dominio. Sin embargo, para el modo relacional encontramos específicamente las siguientes reglas de restricción: 1. Reglas de Integridad de entidad 2. Reglas de Integridad referencial 3. Restricciones de multiplicidad 4. Restricciones generales
REGLA
DESCRIPCIÓN
DEFINICIÓN
Integridad de entidad
Se aplica a las claves principales de las relaciones base.
En una relación base ninguna clave principal puede ser Null. Relación base es una relación que se corresponde con alguna de las entidades del sistema conceptual.
Integridad referencial
Se aplica a claves externas. No se podría crear una tupla con un atributo relacionado externamente que no exista en la relación de origen. Sin embargo si es necesario crear la tupla para después relacionarla externamente, se puede crear el atributo externo con Null si aun no ha sido creado en el origen. Estas restricciones podríamos llamarlas operativas, ya que se implementan de acuerdo a las necesidades o reglamentaciones de la empresa, sin embargo, el soporte de este tipo de restricción puede variar de un sistema a otro.
Si hay una clave externa en una relación, el valor de ésta debe corresponder con el valor de la clave candidata de alguna tupla en su relación de origen, caso contrario el valor de la clave externa debe ser Null.
Restricciones generales
Son reglas adicionales especificadas por los usuarios o administradores de la base de datos que definen o restringen algún aspecto de la organización (empresa)
VISTAS. Terminología Relación base: Es una relación (tabla) nominada (con nombre) que corresponde a una entidad (objeto real) del esquema conceptual y cuyas tuplas (filas) están almacenadas físicamente en una base de datos (en el disco duro). Vista: Es el resultado dinámico de una o mas operaciones relacionales que operan sobre relaciones base para producir otra relación virtual. Una vista es una relación virtual que puede producirse en el momento que sea solicitado por un usuario concreto, y de hecho se genera el momento de dicha consulta. No ocupan espacio de almacenamiento pero su definición si ocupa espacio, es decir, existe un ahorro de espacio significativo ya que solo se define como se va a generar esta relación virtual , pero los datos están solamente en las relaciones base. Resultado dinámico: Significa que cualquier cambio que se realice en las relaciones base se verán reflejadas inmediatamente en las vistas. Es decir, el término dinámica se refiere a que existe un cambio permanente, claro, dependiendo de las relaciones base sobre las que esté construida la vista. Las vistas representan una de las expresiones más clarea de la independencia de datos lógica de la arquitectura ANSI-SPARC.
PROPÓSITO DE LAS VISTAS - Seguridad potente ya que los usuarios solamente ven lo que la vista le permite ver de acuerdo a las restricciones operativas de la organización. La organización física de la BD está oculta detrás de las vistas. - Permite a los usuarios acceder solamente a los datos que necesita, de forma personalizada. Es decir que incluso los mismos datos pueden ser vistos por diferentes usuarios de forma distinta. - Al estar alejadas de las relaciones base, las operaciones que se generan en las vistas son más simples. Es decir, que en la vista pued combinar datos de diferentes relaciones mediante operaciones simples y será el SGBD el que se encargue de traducir todas ellas a operaciones entre relaciones base. - En la vista, los atributos pueden ser renombrados y cambiados el orden incluso, sin que esto afecte a las relaciones base, que mantendrán inamovible su estructura. Nuevamente tomamos el término dinámicas para definir esta particularidad. - Independencia lógica de la arquitectura ANSI-SPARC ACTUALIZACIÑON DE LAS VISTAS Cualquier cambio en una relación base se verá reflejada automáticamente en las vistas que dependan de estos cambios, es decir, si en la relación base cambiamos un precio de un producto, este precio se verá automáticamente reflejado en todas las vistas y operaciones que el atributo precio forme parte. Sin embargo, no todas las vistas están autorizadas a cambiar las relaciones base. Para ello se definen algunas condiciones para que esto sea posible en la mayoría de los SGBD. O sea, que las condiciones para que una vista pueda cambiar una relación base son las siguientes: - Se permite actualizar mediante una vista que esté definida usando una consulta simple en la que esté involucrada una única relación base y que contenga la clave (llave) principal o una -
candidata de dicha relación. No se permiten actualizaciones de datos en vistas que impliquen múltiples relaciones base No se permiten actualizaciones mediante vistas que impliquen operaciones de agregación o de
agrupación. SE DEFINEN ENTONCES CLASES DE CISTAS QUE SON: TEÓRICAMENTE ACTUALIZABLES,
TEÓRICAMENTE NO ACTUALIZABLES Y PARCIALMENTE ACTUALIZABLES. ALGEBRA RELACIONAL Y CÁLCULO RELACIONAL Concepto de Álgebra Relacional.- Es un lenguaje teórico con operaciones que se aplican a una o más relaciones, con el fin de definir (presentar crear) otra relación sin modificar las relaciones originales. Es un lenguaje de manipulación de una relacion cada vez. Cómo funciona: Tanto los operandos como los resultados son relaciones, de esta manera la salida de una operación puede utilizarse como entrada de otra operación, creando operaciones anidadas entre ellas. Propiedad de cierre: Es cuando el resultado de una operación relacional es otra relación. A esto se le llama propiedad de cierre. OPERACIONES Operaciones Unarias. Existen dos operaciones unarias en Álgebra Relacional, a saber: Selección o Restricción.- Se representa con la letra griega sigma : . La selección o restricción se aplica a una relación (R) y define otra relación (como se dijo antes toda operación de álgebra relacional puede generar como resultado otra relación, propiedad de cierre) que contiene únicamente las tuplas que cumplen con la condición del predicado (predicado: argumento para definir una nueva relación) Ej predicado (R) Donde es la operación de selección, predicado es el argumento que define las condiciones de selección y R es la relación sobre la que se aplicará dicha selección.
Apellido = Gómez (Alumnos) Donde define la operación Selección o restricción, Apellido = Gómez, indica que se creará una nueva relación que con todas las tuplas que contengan Gómez en el atributo Apellido. Y (Alumnos) nos indica que toda esta información saldrá de la r elación (tabla) llamada “Alumnos”.
Proyección.- Se representa con la letra griega Pi : π. La proyección se aplica a una relación (R) y define otra relación (como se dijo antes toda operación de álgebra relacional puede generar como resultado otra relación, propiedad de cierre) que contiene un subconjunto vertical de dicha relación, extrayendo los valores que cumplen con la condición del predicado a excepción de los duplicados. Ej
π predicado (R)
Donde π es la operación de proyección, predicado es el argumento que define las condiciones de selección y R es la relación sobre la que se aplicará dicha selección.
π Cédula, Apellido, Semestre (Alumnos)
Donde π define la operación Proyección, Cédula, Apellido, Semestre, indica que se creará una nueva relación que con todas los atributos nombrados, y (Alumnos) nos indica que toda esta información saldrá de la relación (tabla) llamada “Alumnos”.
Las llamadas operaciones unarias nos permiten extraer información de una única relación. Sin embargo, hay ocasiones en las que es necesario combinar información de diversas relaciones. Entonces acudimos a las Operaciones Binarias, que detallamos y explicamos acontinuación. Operaciones Binarias. Operaciones de Conjuntos. Unión: R ∪ S, define una relación que contiene todas las tuplas de R como de S, sin repetir las duplicadas. R y S deben ser compatibles con respecto a la unión. Esto quiere decir que las dos deben tener el mismo grado y el n-ésimo término de la relación R debe tener el mismo dominio de la relación S. Para definir la nueva relación resultado de la unión, primero nos valemos de la operación unaria Proyección, para tener los atributos que necesitamos pero obviamente los combinamos, es decir, unimos una operación unaria de proyección de una relación con otra proyección de otra relación, en donde los atributos seleccionados serán el resultado. Matemáticamente podemos definir la Unión como el Or Diferencia de conjuntos: R – S, define una relación que está compuesta por las tuplas que se encuentran en R pero no en S Como en el caso anterior, las relaciones deben ser compatibles. Podemos decir que la diferencia toma todos los valores de R mediante una proyección, y resta los valores de las tuplas que tiene R en el mismo atributo. EJEMPLOS Dado las relaciones R= Clientes y S= proveedores Clientes codigo_ nombre_ estado_civil 001 Pablo Lescano Soltero 002 Dalia Silva Viudo 003 Sandra Morales Casado 004 Patricio Noboa Casado 005 Susana Abdo Casado Proveedores
codigo_ 001 002 003 004 005
nombre_ Santiago Noboa Patricio Noboa Sandra Morales Karyna Pastor Rosa Caranqui
estado_civil Casado Viudo Casado Casado Soltero
Se desea dar una tarjeta de felicitación por navidad a clientes y proveedores. Esto debe generar una lista de proveedores y clientes, como un cliente puede ser proveedor y viceversa, usamos unión para que los que estén duplicados se excluyan dichas duplicaciones. R ∪ S Hacemos la proyección de R y S π nombre_ (Clientes) π nombre_ (Proveedores) R ∪ S nombre_ Pablo Lescano Dalia Silva Sandra Morales Patricio Noboa Susana Abdo Santiago Noboa Karyna Pástor Rosa Caranqui
Se desea dar una tarjeta de felicitación por navidad solo a clientes pero excluyendo a aquellos clientes que son además proveedores, ya que para los proveedores hay otro tipo de tarjeta. Esto debe generar una lista solamente de clientes que no sean proveedores. R-S Hacemos la proyección de R y S nombre_ (Clientes) - nombre_ (Proveedores) R - S nombre_ Pablo Lescano Dalia Silva Susana Abdo
Intersección: R ∩ S. La intersección define una relación que devuelve los datos que están en R y en S, es decir, los datos que son comunes entre las relaciones base. Nuevamente las relaciones debe ser compatibles para la unión. Basados en el ejemplo anterior la relación resultante sería: R∩S
nombre_ Patricio Noboa Sandra Morales Producto Cartesiano: R x S. Define una relación que es la concatenación de cada tupla de la relación R con cada tupla de la relación S. Es decir, la relación resultante, va combinando cada registro o tupla de R con cada uno de los registros o tuplas de S. Para el ejemplo anterior, la relación resultante sería como sigue, tomando en cuenta que si el atributo tiene el mismo nombre, se añade antes del nombre del atributo el nombre de la relación como prefijo. RxS client e_cod
cliente_nombre
cliente_estado_ civil
provee dor_cod
proveedor_nombre
proveedor_estado_c ivil
001 001 001 001 001 002 002 002 002 002 003 003 003 003 003 004 004 004 004 004 005 005 005 005 005
Pablo Lescano Pablo Lescano Pablo Lescano Pablo Lescano Pablo Lescano Dalia Silva Dalia Silva Dalia Silva Dalia Silva Dalia Silva Sandra Morales Sandra Morales Sandra Morales Sandra Morales Sandra Morales Patricio Noboa Patricio Noboa Patricio Noboa Patricio Noboa Patricio Noboa Susana Abdo Susana Abdo Susana Abdo Susana Abdo Susana Abdo
Soltero Soltero Soltero Soltero Soltero Viudo Viudo Viudo Viudo Viudo Casado Casado Casado Casado Casado Casado Casado Casado Casado Casado Casado Casado Casado Casado Casado
001 002 003 004 005 001 002 003 004 005 001 002 003 004 005 001 002 003 004 005 001 002 003 004 005
Santiago Noboa Patricio Noboa Sandra Morales Karyna Pastor Rosa Caranqui Santiago Noboa Patricio Noboa Sandra Morales Karyna Pastor Rosa Caranqui Santiago Noboa Patricio Noboa Sandra Morales Karyna Pastor Rosa Caranqui Santiago Noboa Patricio Noboa Sandra Morales Karyna Pastor Rosa Caranqui Santiago Noboa Patricio Noboa Sandra Morales Karyna Pastor Rosa Caranqui
Casado Viudo Casado Casado Soltero Casado Viudo Casado Casado Soltero Casado Viudo Casado Casado Soltero Casado Viudo Casado Casado Soltero Casado Viudo Casado Casado Soltero
Viendo la operación de forma general el resultado sería el anterior, sin embargo, en la praxis esta operación por sí misma no tiene una gran utilidad si no se la combina con las operaciones unarias. De hecho en la relación R x S hay más datos de los que se requieren en realidad. Es posible limitar la cantidad de datos a lo que estrictamente necesitamos de la siguiente manera. Ej. Queremos conocer todos nuestros clientes y proveedores casados.
Aplicamos la Selección, con el predicado que seleccione las tuplas que digan soltero en el atributo estado_civil con el prefijo de cada relación. Y aplicamos la proección para que devuelva los valores de los atributos nombe_ Clientes.estado_Civil = Proveedores.estado_Civil && Cliente.nombre_ == Proveedor.nombre_ (π nombre_(Clientes)) x (π nombre_(Proveedores))
El resultado sería
Ejercicio página 99 Cuestiones de Repaso 4.1. ¿Cuál es la diferencia entre lenguaje procedimental y no procedimental?. Como clasificaría el álgebra relacional y el cálculo relacional. Lenguaje procedimental es el que indica como ha de realizar lo que quiere consultar. El no procedimental es el que indica qué quiere consultar, no la forma como hacerlo. El álgebra relacional es un lenguaje procedimental, en cambio el cálculo relacional es no procedimental. 4.2. Explique los siguientes términos: Relacionalmente completo: Se refiere a un lenguaje capaz de producir una nueva relación obtenida mediante cálculo relacional. Cierre de las operaciones relacionales: Se refiere a la propiedad que tienen las operaciones relacionales de producir resultados relacionales, es decir, el resultado de una operación relacional puede ser usado como entrada de otra operación relacional. 4.3. Defina las 5 operaciones básicas del álgebra relacional. Defina las operaciones de combinación, intersección y división en términos de estas 5 operaciones básicas. 4.4. Diferencia entre las operaciones básicas de combinación. Combinación Theta.- Esta operación devuelve una relación que es el producto cartesiano de dos relaciones que cumplen con una condicional. Es decir que satisfacen un predicado F (llámese F a una fórmula) Equicombinación.- Llámese equicombinación a un tipo de combinación theta cuyo predicado F debe satisfacer una igualdad. Combinación Natural.- Se dice de la combinación que devuelve una relación de las tuplas de R y de S que cumplen los atributos x. Es una forma de intersección, pero en el caso del Join (Combinación natural) se elimina uno de los ejemplares de cada atributo común. Combinación Externa (Izquierda).- Es una forma del Join que además de las tuplas resultantes de una combinación natural se agregan las de la izquierda de la operación, son embargo, como estos valores no tienen correspondencia en el lado derecho devuelven un valor null. Semicombinación.- Vendría a ser el resultado de las tuplas que cumplen cierta condición F pero solamente las de R. 4.5. 5.6. 4.7. 4.8. Describa las relaciones que se generarían mediante las siguientes operaciones de álgebra relacional. a. hotelNo.( Price > 50 (Room)) DESARROLLO PUNTOS DE LIBRO 4.1 Cual es la diferencia entre Lenguaje procedimental y no procedimental. El lenguaje procedimental indica como hacer las consultas, mientras que el no procedimental se limita solamente a decir que es lo que quiere consultar. -
4.3. Las 5 operaciones básicas del álgebra relacional son: Selección: Define una relación conformada por las tuplas de otra. Es una operación unaria Proyección: Define una relación con los atributos de otra relación. Es operación unaria. Producto Cartesiano: Cada una de las tuplas de una relación se conbina con cada una de las tuplas de la otra relación. Es una operación binaria. Unión: Une la información contenida por las tuplas, siempre y cuando cumplan con la compatibilidad con respecto a la unión. Operación binaria. Diferencia: Las tuplas de R que no estén en S.
4.3.b. Combinación: es un produco cartesiano con una función booleana que condicione dicho producto. Intersección:
SOLO RESPUESTAS 4.10. a. Muestra los nombres de los hoteles que están en Londres b. Muestra los nombres de los hoteles que tienen habitaciones con precio mayor a 50 c. Muestra los o el nombre del hotel donde esté hospedado un pasajero “John Smith”
d. Muestra si hay una doble entrada de pasajero y si la hay, muestra el nobre del pasajero, el nombre del hotel, y las fechas mencionadas. CUESTIONES DE REPASO. SOLO RESPUESTAS, LAS PREGUNTAS ESTAN EN EL LIBRO 5.1. Componentes: 5.1.1. DDL (Lenguaje de definición de datos), define la estructura de la base de datos y controla el acceso a los datos 5.1.2. DML (Lenguaje de Manipulación de Datos), sirve par extraer y actualizar los datos. 5.2. Ventajas y desventajas 5.2.1. Ventajas 5.2.1.1.Es un lenguaje relativamente fácil de aprender. 5.2.1.2.Es un lenguaje no procedimental. 5.2.1.3.Es de formato prácticamente libre con respecto a la ubicación de las palabras en la pantalla. 5.2.1.4.Las cláusulas están formadas por palabras inglesas fáciles de recordar. 5.2.2. Desventajas 5.2.2.1.No contempla ningún comando de control de flujo. 5.2.3. SELECT 5.2.3.1.SELECT.- indica los atributos de los que se extraerá la información. 5.2.3.2.FROM.- Indica la relación (tabla) a la que pertenece el o los atributos indicados en SELECT 5.2.3.3.ALL.- Aunque por default, SELECT devuelve todos los valores, incluidos los repetidos, hay ocasiones en las que es necesario indicar expresamente que sontodas las tuplas, incluso las repetidas las que se necesita extraer. Para ello esta la cláusula ALL. 5.2.3.4.DISTINCT.- Esta cláusula elimina los datos repetidos de las tuplas. 5.2.3.5.* .- Este símbolo (asterisco) nos indica que se tomarán todos los atributos de la relación. 5.2.3.6.WHERE.- Esta cláusula permite condicionar mediante operadores de comparación =, < , >, etc., cláusulas de condición (in, not in, etc) el resultado de un SELECT. 5.2.3.7.IN y NOT IN.- Son cláusulas que ejercen una selección de los datos a presentarse por medio de la comparación si están incluidas o no están incluidas en una columna. Se diferencia de una comparación simple (con =) porque puede funcionar como excluyente, es decir, puedo presentar los datos que incluyan cierto s valores, o los que excluyan estos valores. 5.2.3.8.LIKE y NOT LIKE.- Esta cláusula sirve para hacer selección de tuplas comparando patrones, es decir, en vez de decir x = „y‟, lo que compara es con los caracteres especiales como son el % y el _. Se usa el % para representar cualquier de n caracteres, es decir si yo pido que busque cualquier ciudad que empiece con m pues le diré que busque M%. En cambio el _ representa cualquier carácter individual, ejemplo si quiero encontrar todas las palabras de 5 letras que empiecen con m diré: m_ _ _ _. 5.2.3.9.NULL y NOT NULL.- El funcionamiento es similar al IN y NOT IN, con la diferencia que el valor que compara es el NULL y NOT NULL, con todas las consideraciones que la palabra NULL tiene en bases de datos.
5.2.4. Restricciones que se aplican a las instrucciones de agregación: 5.2.4.1.Estas funciones operan sobre una sola columna de la tabla. 5.2.4.2.Las funciones SUM y AVG solo pueden usarse con datos numéricos, las demás con cualquier tipo de dato. 5.2.4.3.A excepción de COUNT todas las funciones eliminan los valores NULL antes de hacer la operación. Para COUNT hay que expresar exactamente lo que se uqiere por medio de ALL y DISTINCT. 5.2.4.4.La función DISTINCT no tiene ningún efecto en MIN y MAX, porque null es null, pero en SUM y AVG si influye en el resultado 5.2.4.5.La cláusula GROUP BY agrupa la respuesta de acuerdo al parámetro que se le dé, por ejemplo, no importa los atributos que solicitemos, éstos pueden estar agrupados de acuerdo a cualquier otro atributo, e incluso de acuerdo a alguno de los mismos. WHERE es la función que condiciona la selección tomando en cuenta directamentre los atributos, HAVING hace lo mismo que WHERE pero tomando en cuenta los grupos determinados por GROUP BY. 5.2.4.6.La subconsulta es lo que llamamos consulta anidada, es decir que dentro de una consulta podemos hacer otra consulta, que por lo general debe hacérsela después de WHERE y el condicional que comparará con el resultado de dicha subconsulta. En cambio la combinación (JOIN) concatena dos tablas en base a parámetros dados (igual que la combinación el álgebra relacional) y de ahí realiza la selección. Esta última suele aplicarse a relaciones uno a muchos. La subconsulta no deberá aplicarse a este tipo de relaciones. Las reglas de las subconsultas son: No usar ORDER BY dentro de una subconsulta. En la consulta externa si se puede. La lista SELECT de la subconsulta debe tener solo una columna (atributo) o expresión. La subconsulta debe ubicarse a la derecha del operando de comparación.
5.7. Todos los detalles de los hoteles SELECT DISTINCT * FROM Hotel; 5.8. Listado de todos los detalles de hoteles situados en Londres SELECT DISTINCT * FROM Hotel WHERE city = „Londres‟;
5.9. Nombres y direcciones de todos los huéspedes que viven en Londres, ordenado alfabéticamente por nombre. SELECT DISTINCT
METODOLOGIA DE DISEÑO DE BASES DE DATOS 1. Que es una metodología de diseño? Es UN ENFOQUE ESTRUCTURADO QUE UTILIZA PROCEDIMIENTOS, HERRAMIENTAS Y TECNICAS Y AYUDAS PARA GENERAR DOCUEMNTACION PARA FACILITAR EL PROCESO DE DISEÑO Y SERVIR DE SOPORTE. 2. Una metodología de diseño está compuesta por FASES – cada fase compuesta por PASOS. 3. La metodología del diseño también sirve para GESTIONAR, PLANIFICAR, CONTROLAR Y EVALUAR. 4. DISEÑO CONCEPTUAL, LÓGICO Y FÍICO DE LA BD.
FASES DISEÑO CONCEPTUAL
Y O T P E C N O C
DISEÑO LOGICO
- Proceso de construcción de - Igual que el diseño un modelo de los datos conceptual pero basándose utilizados en una en un modelo de datos específico organización, independiente (ej. modelo relacional), aún es de todas las consideraci ones independiente del SGBD. fí sicas. - Inicia con la creación de un modelo conceptual de los datos, este modelo es independiente de los detalles de implementación.(SGBD, App, DML, DDL, hardware, etc.)
DISEÑO FISICO
- Es el proceso de generar una descripción de la implementación de la base de datos en
almacenamiento secundario. Describe las relaciones base, organización de archivos e índices para un acceso eficiente a los datos. - El diseño físico permite tomar decisiones sobre cómo implementar la base de datos. El diseño físico
ya esta adaptado a un SGBD específico. PASO 1 1. Construir un modelo conceptual de los datos. 1.1. Identificar los tipos de entidad. 1.2. Identificar los tipos de relación. 1.3. Identificar y asociar los atributos con los tipos de entidad y de relación. 1.4. Determinar los dominios de los atributos. 1.5. Determinar atributos de clave candidata, principal y alternativa. 1.6. Considerar el uso de conceptos de modelado avanzado (opcional si aplica). 1.7. Comprobar si el modelo tiene redundancias. 1.8. Validar el modelo
PASO 2 PASO 3 2. Construir y validar el 3. Traducir el modelo lógico modelo lógico de datos. al SGBD seleccionado. 2.1. Determinar las 3.1. Diseñar las relaciones para el relaciones base. modelo lógico de 3.2. Diseñar la datos. representación de los 2.2. Validar las relaciones datos variados. con técnicas de 3.3. Diseñar las normalización. restricciones 2.3. Validar las relaciones generales. comprobando con las PASO 4 transacciones de los 4. Diseñar la organización usuarios. de los archivos y los 2.4. Comprobar las índices. restricciones de 4.1. Analizar las integridad. transacciones. 2.5. Repasar el modelo 4.2. Seleccionar la lógico con los organización de los usuarios. archivos. 2.6. Combinar los 4.3. Seleccionar los modelos lógicos en un
conceptual comprobando las transacciones de los usuarios. 1.9. Repasar y revisar el modelo conceptual con los usuarios.
modelo global (opcional si aplica). 2.7. Verificar las consideraciones derivadas del crecimiento futuro.
5. 6. 7.
8.
5. -
Índices. 4.4. Estimar los requisitos de espacio de disco. Diseñar las vistas de usuario Diseñar los mecanismos de seguridad. Considerar la introducción de una cantidad controlada de redundancia. Monitorizar y ajustar el sistema final.
FACTORES DRÍTICOS EN EL DISEÑO DE A BD. Trabajar interactivamente con los usuarios finales. Seguir una metodología estructurada durante todo el proceso. Emplear una técnica centrada en los datos. Incorporar consideraciones estructuradas y de integridad (restricciones) durante el proceso. Combinar técnicas de conceptualización, normalización y validación de transacciones. Emplear diagramas para representar los modelos ( modelado) de los datos. Emplear lenguaje de diseño de bases de datos (DBDL, Database Design Language). Construir un diccionario de datos como complemento de los diagramas. Disposición para repetir y reveer determinados pasos hasta encontrar la mejor opción.
2. PASO 2. CONSTRUCCIONS DEL MODELO CONCEPTUAL 1.1. Identificar los tipos de entidad. 1.2. Identificar los tipos de relación. 1.3. Identificar y asociar los atributos con los tipos de entidad y de relación. 1.4. Determinar los dominios de los atributos. 1.5. Determinar atributos de clave candidata, principal y alternativa. 1.6. Considerar el uso de conceptos de modelado avanzado (opcional si aplica). 1.7. Comprobar si el modelo tiene redundancias. 1.8. Validar el modelo conceptual comprobando las transacciones de los usuarios. 1.9. Repasar y revisar el modelo conceptual con los usuarios.
1. Construir un modelo conceptual de los datos. Comprende: - Tipos de entidad - Tipos de relación - Atributos y dominio de los atributos - Claves principales y alternativas - Restricciones de integridad 1.1. Identificar los tipos de entidad. Entidad física = objeto físico o “real” Entidad conceptual = objeto conceptual o “abstracto”
Se basa en las especificaciones y requerimientos de la organización. Se analiza los objetos reales y conceptuales y la clasificación, nominación y codificación que la organización ha implementado para cada uno de ellos. Se clasificará las entidades además por su importancia por su jerarquía, posición etc, en el caso de personas, y se buscará una manera de clasificar el resto de entidades eliminando todo tipo de característica o cualidad de otros objetos – entidades. Una manera alternativa de identificar entidades es por su existencia propia, es decir que su existencia sea independiente de la existencia de cualquier otra entidad. Documentación: - Es necesario crear un diccionario de datos con todos los nombres y descripciones recogidas en el primer acercamiento. - Si una instancia o entidad se conoce con diferentes nombres se incluye este alias. 1.2. Identificar los tipos de relación. Objetivo: Identificar las relaciones importantes existentes entre los tipos de entidad.
-
Normalmente las relaciones se indican mediante verbos o expresiones como: Cada empleado trabaja en una sucursal concreta. Cada inmueble(alias) tiene un único propietario que pide tal cantidad de renta. El inmueble es gestionado por un empleado. Puede ser visitado por varios clientes, etc. Considerar el nivel de importancia que las relaciones y las entidades tienen para la organización. Cada palabra u opinión de parte del personal de la organización deberá ser tomada en cuenta. En la mayoría de los casos las relaciones son binarias (como es preferible para nuestros fines) pero hay que tener cuidado cuando existen relaciones complejas, relaciones recursivas, etc. Tomar en cuenta que siempre es mejor tratar de reducir estas relaciones a binarias, mediante las técnicas ya estudiadas. Deberá garantizarse que todas las relaciones mencionadas explícitamente o implícitamente sean expresadas en este paso. Si alguna relación faltara a pesar de haber sido exhaustivo en este paso, será en la etapa posterior de validación de las relaciones. En este paso, nos será de gran utilidad los diagramas de Entidad-Relación que se han estudiado antes, en donde se considera la dirección de las relaciones entre las entidades, etc. Utilizando la más reciente notación orientada a objetos, la UML (Unified Modeling Language). Aunque hay otras notaciones alternativas que cumplen una función similar.
Una vez que se ha identificado las relaciones, es necesario determinar la multiplicidad de cada relación, es decir, la cantidad posibles de instancias (tuplas) de una entidad que se relacionarán con otra u otras instancias de otra entidad. O sea, relación uno a uno (1..1), uno a muchos (1..*) y muchos a muchos (*..*), considerando que estas son restricciones de multiplicidad de relaciones binarias. Otro punto importante en este paso es la determinación de trampas multiplicativas y restrictivas, es cuando un modelo representa una relación entre dos que como ya sabemos trampa mul tipli cativa entidades pero la ruta entre ciertas instancias (tuplas) es ambigua y tr ampa restr icti va o de corte cuando no existe ruta o relación entre ciertas instancias (tuplas) de una relación que se ha representado. Recordemos que esto puede ser representado mediante una Red Semántica.
En este punto es importante documentar este paso mediante una primera versión del Diagrama de Entidad Relación. 1.3. Identificar y asociar los atributos con los tipos de entidad y de relación. En este paso necesitamos analizar e identificar los atributos que cada entidad debe tener, en otras palabras, cada entidad debe tener ciertos parámetros, información, atributos o características que serán los que se relacionen posteriormente entre entidades. Es preciso evaluar profundamente los conceptos que emitidos por los usuarios para saber determinar que entra dentro del parámetro atributo.. Para ello vamos a utilizar la clasificación estudiada de los atributos y determinar a cual de ellos pertenece cada uno de ellos. Atributos simples/compuestos.- Un atributo simple es una forma atómica de atributo, es decir que no se puede descomponer, tal es el caso de primerNombre. Este atributo posee un solo dato que representa este atributo. Sin embargo, si queremos ser un poco mas genéricos en la denominación de un atributo podemos decir simplemente nombreCompleto, y éste será un atributo compuesto, ya que iternamente se podría descomponer en primer nombre, segundo
nombre, apellido paterno y apellido materno. Atributos univaluados y mutivaluados.- Una vez más, lo
usual es encontrar atributos univaluados en nuestras entidades, es decir que tienen un solo valor por instancia, tal es el caso del género de un cliente, solo existe la opción de Masculino ó Femenino, sin embargo en otros casos, como por ejemplo el atributo telefonoCliente, el mencionado cliente puede tener dos celulares con números distintos. Éste último será un atributo multivaluado. Atributos derivados.- Son los que el valor depende de otros atributos que son ingresados o fijos en una entidad, los atributos derivados por lo general son calculados a partir de otros valores de otros atributos. Por ejemplo, si tenemos el atributo edadCliente, podemos simplemente ingresar la edad a la fecha, pero claro, esto nos llevaría a tener que actualizar la edad en cada año y tomar en cuenta cuando cumple años (manualmente). Entonces usamos un atributo derivado, es decir, tenemos un atributo simple fechaNacimiento, y en base a esta hacemos el cálculo de la edad actual de nuestro cliente, sin necesidad de actualizar manualmente. Problemas potenciales.- Para problemas potenciales, por ejemplo cuando hemos pasado por alto algunas entidades, atributos o relaciones, es necesario volver atrás en este momento del diseño, ya que todavía está todo en papel y sujeto a cambios incluso radicales. En todo caso se sugiere primero que todo hacer una lista de los atributos totales en forma de relación universal y a medida que se va asociando cada atributo con su entidad y su relación. Eventualmente podremos encontrar atributos que compartan entidades y en consecuencia relaciones, en cuyo caso se pueden dar dos casos: I. Que tenga tantas posibles instancias que sea necesario hacer una entidad aparte. II. Que las posibles instancias sean tan mínimas que sea suficiente con incluir el atributo en una misma entidad. Todo esto a criterio del administrador. Documentación.- La documentación que reflejará los atributos consiste en una tabla que contenga lo siguiente: o Nombre del atributo y su descripción. o Tipo de dato y su longitud. o Alias que el atributo pueda tener
Si el atributo es compuesto o simple y si es el primer caso, que atributos simples lo conforman. o Si el atributo es multivaluado. o Si es derivado, y si es asi como hay que calcularlo. o Los valores predeterminados (DEFAULT) que pueda tener el atributo. 1.4. Determinar los dominios de los atributos. o
Objetivo: Determinar los dominios de los atributos en el modelo conceptual local de los datos.
Una vez determinados todos los atributos posibles es momento de determinar cual es el dominio de cada atributo, es decir, los valores que cada atributo puede tomar, con sus restricciones, tipos de dato, etc. La documentación que refleje este paso es un Diccionario de Datos, en donde se describa a detalle el dominio de cada atributo. 1.5. Determinar los atributos para claves candidatas, principal y alternativa. Objetivo: Identificar los atributos que se tomarán en cuenta para claves candidatas y desde ahí las claves principales y alternativas.
Todo este paso lo haremos con la metodología estudiada para determinar la importancia, unicidad y restricciones de los atributos que serán tomados en cuenta. Para ello consideremos lo siguiente: Clave Candidata es un conjunto mínimo de atributos de una entidad queidentifican unívocamente a cada instancia de una entidad. Clave Principal es una o más claves candidatas seleccionadas para identificar unívocamente a cada instancia de la entidad. Importante recordar para esto que existen claves simples y compuestas. Claves Alternativas son las claves candidatas que no se seleccionaron como claves principales.
Una técnica para ayudarnos a seleccionar una clave principal considera lo siguiente: La clave candidata con el mínimo número de atributos. La clave candidata cuyo valor sea menos probable que cambie. La clave candidata con el menor número de caracteres(para aquellas que tengan atributos textuales). La clave candidata que tenga el valor máximo más pequeño (para las que tengan atributos numéricos). La clave que sea más fácil de utilizar desde el punto de vista del uuario.
La documentación que genera este paso
consiste en almacenar la identificación de claves principales
y alternativas en el diccionario de datos. 1.6. Considerar el uso de conceptos de modelado avanzados (paso opcional) Este paso considera, si fuera necesario, la aplicación de conceptos de modelado avanzado como la especialización/generalización, agregación y composición, clases y subclases. Se estudiará esto más adelante. 1.7. Comprobar si el método tiene redundancia. Objetivo: Comprobar la presencia de redundancia en el modelo. Para ello contamos con dos actividades principales que comprenden: Reexaminar y examinar las relaciones 1:1 Es posible que se encuentren entidades que aunque tengan diferentes nombres cumplan la misma función, quizás con la diferencia de que una de ellas tiene un atributo que complemente el concepto de la entidad. Si fuera el caso deberán fusionarse y seleccionar la clave principal que represente unívocamente a cada instancia in redundancia. Eliminar las relaciones redundantes.
Importante: Una relación es redundante si puede obtenerse la misma información mediante otras relaciones. Se deberá tener mucho cuidado al analizar las redundancias que pueden presentar también una aparente redundancia pero que en realidad no es tal. He ahí la importancia de este punto. Considerar la dimensión temporal. Importante: La dimensión temporal es muy importante a la hora de verificar si existe redundancias. Este término dimensión temporal, significa en realidad examinar las dependencias con mucha agudeza, ver las relaciones que puede y no puede tener, y cual de ellas se puede eliminar o no, en base al análisis de la realidad. 1.8. Validar el modelo conceptual comprobando las transacciones de los usuarios. Objetivo: Verificar y garantizar que el modelo conceptual soporte las transacciones requeridas. El punto de este paso consiste en someter a una comprobación del modelo conceptual resultante de los pasos anteriores, gestionando cada transacción requerida por los usuarios de manera manual. Si esta prueba ha sido superada entonces podremos continuar, si alguna dificultad se presenta con respecto a alguna transacción en especial será momento de regresar tantos pasos como sean necesarios para implementar las transacciones fallidas, una vez realizado esto nuevamente validamos lo reparado. Vale insistir la utilidad de estos pasos ya que todo esto se realiza aún en papel y sin generar ni desperdiciar recursos importantes. Par este paso nos valemos de dos elementos importantes que nos ayudarán a cumplir con lo requerido, a saber: Descripción de las transacciones: Mediante esta técnica comprobamos que toda la información (entidades, relaciones atributos) requerida para cada transacción se encuentra en el modelo conceptual. Un ejemplo podría ser: Transacción (n): Proporcionar todos los detalles de un cliente incluido el número de compras que ha realizado en un período determinado. Utilización de las rutas de transacciones: Esta segunda técnica para validar el modelo conceptual que hemos realizado consiste en representar diagramáticamente la ruta tomada por cada transacción dibujándola directamente en el diagrama Entidad-Relación. Este modelo de diagrama permite al diseñador visualizar las áreas del modelo que no sean necesarias para las transacciones, así como las áreas que sean críticas para las mencionadas transacciones.
1.9. Repasar el modelo conceptual con los usuarios Este paso consiste muy explícitamente en una revisión paso por paso con el usuario el modelo conceptual desarrollado hasta este momento y como consecuencia de ello se presentan dos posibilidades, la una, que el usuario encuentre algunas observaciones o inconsistencias en el modelo, y en consecuencia que debamos repetir los pasos que sean necesarios hasta satisfacer la demanda del cliente; y por otro lado puede presentarse que todo el esquema presentado esté acorde a los requerimientos del usuario. Como fin de cualquiera de las dos opciones es necesario contar con que el usuario “autorice” el modelo y prácticamente de por aceptado que el modelo representa “verdaderamente” la parte de la organización que estamos modelando.
2. PASO 2 – Construir y validar el diseño lógico de los datos. El objetivo de este paso es traducir el modelo de datos conceptual a un modelo lógico y después validar este modelo para comprobar que sea estructuralmente correcto y capaz de soportar las transacciones requeridas. 2.1. Determinar las relaciones para el modelo lógico de datos. 2.2. Validar las relaciones con técnicas de normalización. 2.3. Validar las relaciones comprobando con las transacciones de los usuarios. 2.4. Comprobar las restricciones de integridad. 2.5. Repasar el modelo lógico con los usuarios. 2.6. Combinar los modelos lógicos en un modelo global (opcional si aplica). 2.7. Verificar las consideraciones derivadas del crecimiento futuro. 2.1. Determinar las relaciones para el modelo lógico de datos. Objetivo: Crear tablas relacionales para el modelo lógico de los datos que representen las entidades, relaciones y atributos que se haya identificado.
Para esto, vamos a describir como derivar las tablas relacionales para las siguientes estructuras que pueden aparecer en el modelo conceptual. 1. Tipos de entidades fuertes.- Para cada entidad fuerte (tipo de entidad cuya existencia no depende de otro tipo de entidad) crearemos una tabla relacional que incluya todos los atributos simples de esa entidad. Para atributos compuestos los convertiremos en simples poniendo a cada simple como atributo aparte. 2. Tipo de entidades débiles. - Para cada entidad débil (que son cuya existencia depende de otra entidad) crearemos una tabla relacional que incluya todos sus atributos simples. La identificación de la clave principal se deja sin valor pero indicando que posteriormente (cuando se definan las relaciones) se va a determinar. 3. Tipos de relaciones binarias uno a muchos (1: *).- Para cada relación binaria 1:* se pone en el lado 1 a la entidad padre, mientras que en el lado * (muchos) se coloca la entidad hija. Para relacionar estas dos tablas colocamos en la entidad hija una copia de la clave principal de la entidad padre. 4. Tipos de relaciones binarias uno a uno (1:1) .- Para este tipo de relación hacemos uso de las restricciones de participación, que como hemos estudiado determinan si todas las instancias de una entidad participan en una relación o solo algunas. Es decir, mediante estas restricciones de participación decidiremos si es mejor combinar las dos entidades en una sola tabla relacional o crear dos tablas relacionales y y colocar una copia de la clave principal de la una en la otra. Mediante las restricciones de participación se pueden generar los siguientes casos: Participación obligatoria en ambos lados de la relación 1:1 – En este caso se deben combinar en una única tabla relacional y elegimos una de las claves principales de las entidades originales como clave principal (la más representativa) y si existe, la restante queda como clave alternativa. Participación obligatoria en un solo lado de la relación 1:1 – En este caso identificamos la relación padre – hija mediante las restricciones de participación,. La entidad que tiene participación opcional en la relación se la designa como padre mientras que la que tiene participación obligatoria se la designa como hija. Una copia de la clave principal de la entidad padre deberá copiarse en la entidad hija. Participación opcional en ambas partes de la relación 1:1 – En este caso la designación de entidades padre e hija es arbitraria a menos que nos llegue más información que nos ayude a decidir en un sentido u otro. 5. Relaciones recursivas uno a uno (1:1).- Para este caso actuamos igual que en las relaciones con participación obligatoria en ambos lados, tomando en cuenta que a ambos lados de la relación se encuentra la misma entidad. Haremos una copia de la clave principal en la única tabla resultante. Para el caso de relación recursiva 1:1 con participación obligatoria en un solo lado de la relación se pueden tomar dos opciones. La primera se actuará como el caso anterior, es decir combinando
