1. BREVE HISTORIA DE LAS BASES DE DATOS 3
2. QUE ES UNA BASE DE DATOS? 6
3. LA INFORMACIÓN COMO RECURSO CORPORATIVO 3
Ventajas y Desventajas de un Sistema de Bases de Datos 7
Funciones de un Sistema Gestor de Bases de Datos 7
4. NIVELES DE ABSTRACCIÓN DE UNA BASE DE DATOS 9 5. PROCESO DE DESARROLLO DE UNA BASE DE DATOS 11 6. LAS BASES DE DATOS Y EL DESARROLLO DE APLICACIONES 13
7. MODELAMIENTO CONCEPTUAL DE DATOS 15
8. ENTIDADES 17 9. RELACIONES 19 10. MATRIZ DE RELACIONES 22 11. LOS ATRIBUTOS 23 12. IDENTIFICADORES UNICOS 25 13. LA NORMALIZACIÓN 29 14. RELACIONES JERÁRQUICAS 34 15. RELACIONES RECURSIVAS 35
LA INFORMACIÓN COMO RECURSO
CORPORATIVO
En los últimos tiempos, se ha empezado a considerar la información como un recurso estratégico de una organización; pues le facilita su supervivencia y le permite, además, ser competitiva en el mercado. También le permite anticiparse a los cambios futuros y adaptarse mucho más rápidamente a ellos.
De la información que una organización almacene y de cómo esté organizada esta información, dependen cuáles preguntas se pueden formular acerca de su gestión actual o pasada, tanto internamente como en el entorno.
El tratamiento estadístico con datos históricos es factor clave en el futuro de la organización y vital en su planeación.
La calidad y oportunidad de las decisiones a todos los niveles depende en gran medida de hacer llegar la información correcta en el momento adecuado, a las personas que la necesitan.
La información se debe considerar como otro recurso corporativo de la misma manera que se considera el recurso humano o los recursos físicos. Por lo tanto, la administración de la información debe implicar:
a) Planear su adquisición por anticipado.
b) Conseguirla y guardarla antes de necesitarla. c) Protegerla contra la destrucción o el mal uso. d) Asegurar su calidad.
e) Retirarla de la organización cuando ya no se la requiera. f) Asignarle un responsable.
2. Breve historia de las bases de datos
La cantidad de información que debe manejar una organización para sobrevivir es cada vez mayor. Para ello, deben existir métodos eficientes tanto para el almacenamiento rápido como para la consulta ágil. La tecnología que actualmente es más utilizada para manejar grandes volúmenes de datos es la tecnología de Bases de Datos.
En los inicios de la computación se elaboraban programas de computador a los cuales, siempre que se ejecutaban, se les proporcionaban los datos de entrada y no se veía la necesidad de guardar la información en memoria secundaria, tanto la resultante como la de entrada, para su uso posterior. Con el tiempo, el computador adquiere un uso más comercial en las empresas para llevar la contabilidad, la nómina y otras actividades. Estas tareas, por lo general, necesitaban una serie de datos iguales para usarlos en las diferentes corridas de los programas e implicaban un gran esfuerzo porque había que entrarlos nuevamente, cada vez.
Ante este problema, aparecen los Sistemas de Archivos, donde los datos se almacenan de manera permanente para sobrevivir a los programas que los usan; característica conocida como la persistencia.
Aunque el ambiente de archivos representó un avance en su momento, posteriormente se enfrentaron con tres problemas básicos.
Información de estudiantes Programas Lenguaje
en archivos de desarrollo
nombre, cédula, valor cancelado por matrícula, préstamos, etc. Fortran nombre, carrera, cédula, materias, notas, teléfono, etc. Cobol
nombre, carrera, nota promedio, valor préstamo, caducidad, etc. Pascal
Figura 1. Ejemplo hipotético del Sistema de Archivos
El primer problema, consiste en la alta redundancia de datos. El mismo dato aparece repetido en varios archivos. Las diferentes versiones de un mismo dato pueden estar con un grado de actualización distinto en cada lugar. Esto, además de aumentar los costos de almacenamiento y de reescritura de la información, puede dar lugar a inconsistencias: un directivo puede estar viendo un informe donde se muestra una cosa y viendo por pantalla, otra.
El segundo problema es la inflexibilidad porque cuando se quiere agrupar los datos de cierta manera no se puede hacer, debido a la organización dada en los archivos que no tienen ninguna clase de vínculos o presentan formatos diferentes; como en el ejemplo hipotético de la ilustración 1. Esta inflexibilidad impide resolver rápidamente consultas espontáneas y aunque
Préstamo estudiantil Ingresos y Egresos
los datos existan, la información no puede proporcionarse relacionando datos. Esta es la queja constante de los directivos; que teniendo la información no tienen acceso a ella, en el momento en que la necesitan. El tercer problema que se presenta con el sistema de archivos es el costo de efectuar cambios en las estructuras de los datos porque al cambiar la representación de un dato, se necesita cambiar el programa para que lo reciba de la nueva manera. Además, es altamente probable que los mismos datos se encuentren en otros archivos; entonces los cambios se propagarán de una manera incontrolable por todos los lugares, aumentando el tiempo que el personal especializado debe invertir en el mantenimiento de los programas y, por ende, reduciendo el tiempo que le pudieran dedicar al desarrollo de nuevas aplicaciones.
Uno de los objetivos de los Sistemas de Bases de Datos es tener la posibilidad de usar los datos de nuevas maneras sin generar una reacción en cadena de modificaciones difíciles sobre los otros programas existentes. El propósito, pues, del ambiente de bases de datos es separar cada programa de los efectos de los cambios a los otros programas. También, que todos los programas estén más aislados de los efectos de reorganizar los datos. Esta característica es conocida como independencia de datos. La tecnología de bases de datos proporciona los medios, a las organizaciones para que cumplan con sus objetivos de lograr máximos beneficios (para las entidades sin ánimo de lucro, a prestar un mejor servicio) y ocupar una posición de liderazgo por las razones que se enumeran a continuación.
1. Se logra el desarrollo de aplicaciones más rápidamente porque los programas reutilizan los datos y procedimientos almacenados en la base de datos y con lenguajes de programación de más alto nivel.
2. Hay una mayor participación del usuario final en la creación de las aplicaciones, haciendo el software más tangible y de mayor valor inmediato.
3. El acceso a los datos es flexible y rápido.
4. Se pueden generar informes y formularios de pantalla sin la programación convencional.
5. El usuario final puede, él mismo, extraer la información que necesita y crear nuevos tipos de datos.
En otras palabras, permite a las organizaciones implantar el justo a tiempo para tener mejor y mayor información para la toma de decisiones e incrementar su productividad.
3. DEFINICION DE UNA BASE DE DATOS
Es una colección de datos (actualmente, también de procedimientos o funciones) almacenados de una manera permanente, que pueden ser compartidos y usados con variados propósitos por múltiples usuarios.
Un usuario determinado no tiene que ver todos los datos de la base de datos, sólo aquellos que necesita o esté autorizado para poder cumplir con sus funciones dentro de una organización.
No todos los usuarios perciben los datos de la misma manera, a pesar de que puedan ser extraídos de la misma base de datos. Por ejemplo, la fecha de compra de un artículo puede ser vista por el asistente de mercadeo con un formato que no incluye la hora; mientras que el jefe de bodega sí necesita verla porque, para él, es información valiosa.
Sin embargo, se debe señalar, que la consecución del objetivo de integrar toda la información de una organización para evitar redundancias, esencial para superar las limitaciones de los sistemas de archivos, a su vez, puede generar nuevos problemas o dificultades que se deben resolver. Entre ellos, está el problema del trabajo concurrente o simultáneo de un grupo de usuarios o aplicaciones sobre las mismas piezas de información y también el problema de la seguridad.
Los usuarios de una base de datos se pueden clasificar en tres categorías: el usuario final que interactúa con la base de datos, por lo general, a través, de las aplicaciones, el usuario especialista que es el que diseña y programa las aplicaciones para los usuarios finales y, por último, la persona encargada de administrar la base de datos llamada en forma abreviada DBA (database administrator).
No obstante, cualquier persona con cargos administrativos, ingeniero o profesional cuyo trabajo sea cambiado por los sistemas de bases de datos debería entender los principios de esta tecnología y lo que ello involucra.
3.1 Ventajas y Desventajas de un Sistema de Bases de Datos
3.1.1 Ventajas1. Economía de escala: esencialmente, la concentración de aplicaciones en una sola localidad puede reducir costos: menos cantidad de personas especializadas, en software, etc.
2. Se puede obtener mayor información de la misma cantidad de datos: existe una mayor facilidad para el análisis y la toma de decisiones. 3. Datos y programas compartidos: la reutilización de los mismos datos y
programas, permiten minimizar o controlar la redundancia. 4. Incentiva la adopción de estándares.
5. Consistencia de los datos: está dada por el control o eliminación de la redundancia.
6. Integridad: el DBMS debe velar por el grado de validez y de corrección de los datos. Debe permitir definir reglas que deben cumplir los datos, en la base de datos. Por ejemplo, que el departamento asociado a un profesor sea uno de los existentes en la Universidad.
7. Seguridad: se pueden especificar niveles de acceso con una granularidad más fina, según los perfiles de los usuarios.
8. Flexibilidad y oportunidad: El uso de lenguajes de cuarta generación hacen más fácil la construcción de los programas por parte de los usuarios finales.
9. Mayor productividad de los programadores. Las aplicaciones nuevas pueden desarrollarse en la mitad del tiempo, o menos, que con los sistemas de archivos tradicionales debido al uso de lenguajes de tercera generación.
10. Facilidades para el mantenimiento y reingeniería: se puede cambiar la estructura de los datos sin cambiar los programas que los usan.
3.1.2 Desventajas
1. Tamaño: Un DBMS es un gran conjunto de programas.
2. Mayor susceptibilidad a las fallas: más cantidad de huevos en una sola canasta.
3. Recuperación a las fallas: la recuperación de un DBMS interactivo y multiusuario puede ser muy compleja.
Funciones de un Sistema Gestor de Bases de Datos
Un sistema gestor de bases de datos (DBMS o Database Management System) es el software que sirve de intermediario entre el usuario y la base de datos. Tiene las siguientes funciones:
1. Interactuar en forma transparente con el manejador de archivos del sistema operativo para la actualización, almacenamiento y recuperación de los datos. El usuario, a excepción del DBA, no debería preocuparse por las estructuras internas o por los procedimientos usados para manipularlos.
2. Optimizar la búsqueda de la información.
3. Ofrecer un catálogo asequible por el usuario (autodescriptivo). Un DBMS debe ser capaz de responder a preguntas sobre:
i) Los elementos que conforman la estructura de la base de datos. ii) Las características de los atributos o campos (i.e longitud, tipo de
datos)
iii) Las restricciones.
iv) Los significados de los elementos o datos.
v) Cuáles programas usan cuáles datos y cómo los usan.
4. Manejo de transacciones: para asegurar que todas las actualizaciones se hagan todas o ninguna. Una transacción es una secuencia de pasos para cumplir una tarea, según el punto de vista del usuario final.
5. Controlar el acceso concurrente o simultáneo a los mismos datos para que no existan conflictos por las peticiones de los usuarios o aplicaciones.
6. Servicios de recuperación ante fallas.
i) Permitir hacer respaldos totales o parciales de la base de datos. ii) Creación y mantenimiento de archivos log de transacciones o
bitácoras; que deben ser actualizados antes que los datos mismos. iii) Incluye la identificación de la transacción, hora y fecha de la
misma.
iv) Archivos de imágenes anteriores y posteriores.
v) Permitir la devolución de la base de datos a un estado correcto conocido.
7. Poner en práctica la seguridad para impedir el acceso a los datos a los usuarios no autorizados mediante:
i) El encriptamiento de la información. ii) Los subesquemas o vistas
iii) Privilegios o reglas de autorización: sujeto, objeto, acción y restricción.
iv) Procedimientos definidos por el usuario que pueden aumentar la seguridad.
8. Implantar mecanismos para preservar la integridad de los datos mediante la especificación con:
i) Tipos de datos ii) Valores válidos
iv) Restricciones
9. Servicios para promover la independencia de datos.
10. Otros servicios utilitarios para la administración de los datos.
De lo recién expuesto, se puede apreciar que un sistema gestor de bases de datos debe realizar muchas tareas bastante complejas y de ahí su tamaño y costo.
No obstante, en el mercado se pueden encontrar una gran variedad de sistemas gestores de bases de datos con precios muy disímiles y una de las razones se debe a que no todos ellos cumplen con las funciones que se acaban de mencionar.
Funcionamiento de un DBMS
4. Niveles de abstracción de una base de datos
La manera cómo percibimos la base de datos, según seamos usuarios finales, especialistas o administradores, corresponde con un nivel de abstracción. Análisis sintáctico Verificación de privilegios y de la existencia de los objetos en la base de datos Diccionario de datos Error Optimización de la consulta Manejo de Transacciones Base de datos Bitácora Administración del almacenamiento
Por lo anterior, la ANSI/SPARC ha propuesto una arquitectura considerando tres niveles de abstracción.
Los niveles son tres:
Nivel de visión (vistas parciales) Nivel conceptual (vista comunitaria) Nivel físico (almacenamiento)
1. El nivel de visión o externo es el más cercano a los usuarios, esto significa que se ocupa de la forma cómo los usuarios individuales perciben la base de datos. A diferencia de los otros dos niveles, existen múltiples maneras de percibir la base de datos a este nivel; tantas como grupos de usuarios finales existan en la empresa. Toda vista externa de la base de datos, se define mediante subesquemas.
2. El nivel conceptual es el nivel mediador entre el nivel físico y el de visión, se ocupa de cuáles son los datos reales almacenados en la base de datos y de las relaciones existentes entre ellos. Este nivel, es de interés primordialmente para el usuario especialista. El esquema lógico, correspondiente con este nivel de abstracción, está conformado por la descripción semántica de los datos que conforman la base de datos. 3. El nivel físico o interno es el más cercano a la máquina, es decir, es el
que se ocupa de la forma como se almacenan los datos físicamente en la memoria secundaria. El nivel físico de la base de datos interesa al administrador y al usuario especialista. La descripción de este nivel de abstracción se le denomina esquema físico y está conformado por la descripción de los datos, sus tipos, su tamaño y dominio de acuerdo con un DBMS particular.
Independencia de datos: es una característica de las bases de datos que permiten modificaciones en la definición de un esquema sin afectar, en la medida de lo posible, la reescritura del esquema inmediatamente superior.
Independencia física: cuando un cambio en el esquema físico no conduce a efectuar cambios en el esquema lógico.
Independencia lógica: cuando un cambio en el esquema lógico no conlleva a un cambio en el nivel de visión. Este tipo de independencia es más difícil de lograr que la independencia física.
5. Proceso de desarrollo de una base de datos
El desarrollo de una base de datos, es una técnica “arriba-abajo” que transforma los requerimientos de información en una base de datos en funcionamiento.
REQUERIMIENTOS DE INFORMACIÓN DE LA ORGANIZACIÓN
Estrategia
Diseño Análisis Conceptual de
la Base de Datos
Modelo Entidad-Relación Diseño Diseño lógico
de la Base de
Datos Tablas, Índices, Vistas, Clústeres, Definiciones de espacios
Construcción Implementación de la Base de Datos
El diseño conceptual parte de la especificación de requerimientos y su resultado es el esquema conceptual, cuyo propósito es describir el contenido de información de la base de datos, más que las estructuras de almacenamiento que se necesitarán para manejar la información. Es una descripción de alto nivel que es completamente independiente del software de DBMS que se use, incluso si se pensara en implementar con archivos tradicionales y con algún lenguaje de programación convencional.
El diseño lógico parte del esquema conceptual y da como resultado el esquema lógico. El esquema lógico es una descripción de la estructura de la base de datos que puede procesar el software DBMS. El modelo lógico más usado actualmente, es el modelo relacional que ha sido enriquecido con los modelos orientados por objetos. El modelo lógico no depende del DBMS en particular, sino del modelo de datos usado por el DBMS.
El diseño físico parte del esquema lógico y da como resultado un esquema físico. Es una descripción de cómo está almacenada la base de datos en la memoria secundaria; describe las estructuras de almacenamiento y los métodos usados para tener un acceso efectivo a los datos. Los esquemas lógicos y físicos se expresan haciendo uso del lenguaje de definición de datos del DBMS elegido; la base de datos se crea y se carga, y puede ser probada. Lo mismo, puede probarse las aplicaciones sobre la base de datos y de este modo la base de datos se vuelve operacional.
6. LAS BASES DE DATOS Y EL DESARROLLO DE APLICACIONES
El proceso de desarrollo de la base de datos está estrechamente acoplado con el proceso de desarrollo de aplicaciones:
Requerimientos de la organización
REQUERIMIENTOS DE INFORMACION REQUERIMIENTOS DE APLICACIONES
Estrategia
Modelamiento Modelamiento
Conceptual de Chequeos Cruzados de
Análisis Funciones
Modelo Entidad-Relación Modelo Jerárquico Def de Funciones DFDs
Diseño Diseño de la Diseño de las Base de Datos Chequeos Cruzados Aplicaciones
Tablas, Indices, Vistas, Diseño de módulos Clusters, Definiciones de
espacios
Construcción Construcción Construcción de de la Base de las aplicaciones Datos
BASE DE DATOS EN OPERACIÓN APLICACIONES EN OPERACIÓN
SISTEMA EN OPERACIÓN
Figura 2 Acoplamiento de la visión orientada a los datos y a las aplicaciones
Un enfoque alternativo en el diseño de los sistemas informáticos llamado
orientado a las funciones se desarrolló en la década de 1960 consiste en centrarse en las aplicaciones y no en los datos.
El análisis funcional parte de los requerimientos de aplicaciones que describen las actividades y los flujos de información dentro de una organización para llegar a una especificación formal de los procesos y considera los archivos de datos depósitos de información aislados, utilizados por cada actividad o intercambiados entre ellas; se pierde la visión de la información como recurso corporativo de la organización.
Los enfoques orientados a los datos y a las funciones para el diseño de sistemas informáticos son complementarios, ambos proporcionan características relevantes y se deben relacionar íntimamente como se muestra en la ilustración 2.
Lo anterior, también ha originado un el enfoque llamado orientado a objetos donde se determinan los objetos del dominio del mundo real relevantes en la solución del problema, con sus características y comportamiento y de esta manera juntar los dos enfoques anteriores.
Independiente del enfoque utilizado, la tarea más difícil en el proceso de desarrollo de una base de datos es determinar los datos necesitados por los usuarios, representarlos en la base de datos y asegurar que ellos son, en verdad, usados apropiadamente. Esto se dificulta, aún más, debido a los diferentes nombres que los usuarios dan a un mismo dato, o por el contrario, el mismo nombre para distintos datos.
De lo expuesto, nace la necesidad adicional de la creación de un diccionario de datos donde cada término es definido según el lenguaje de la empresa, buscando una estandarización para los datos y un significado preciso para cada palabra.
7. MODELAMIENTO CONCEPTUAL DE DATOS
Los modelos de datos son usados para describir la realidad. Los diseñadores usan los modelos de datos para construir esquemas que son representaciones de la realidad. La calidad de los esquemas resultantes dependerá, no sólo del modelo elegido, sino también de la habilidad del analista.
Un modelo de datos es una serie de conceptos que se utilizan para describir un conjunto de datos y de operaciones para manipular los mismos. Cuando un modelo de datos describe un conjunto de conceptos de una realidad se llama modelo conceptual.
El bloque de construcción común a todos los modelos conceptuales de datos es una pequeña colección de mecanismos de abstracción: clasificación (agrupación de una clase de objetos con características comunes), agregación (una nueva clase formada por la reunión de varios objetos) y la generalización o especialización (una relación de subconjunto entre los elementos de dos o más clases).
La abstracción es un proceso mental que se aplica al seleccionar algunas características y propiedades de un conjunto de objetos y excluir otras no pertinentes.
En el modelamiento conceptual, se identifican las propiedades estructurales (sobre los objetos, sus atributos y relaciones) y dinámicas (operaciones sobre los objetos) además de ciertas restricciones de integridad, de un dominio de aplicación con miras a su transformación en un modelo de más bajo nivel.
Los modelos conceptuales deben ser buenas herramientas para representar la realidad; por esta razón debe poseer, entre otras las siguientes características:
1. Expresividad: los modelos más ricos en conceptos son más expresivos. Por ejemplo, la mayoría de los modelos conceptuales hacen uso frecuente de la abstracción de generalización lo que permite la representación de una gran variedad de restricciones de integridad.
2. Simplicidad: un modelo conceptual debe ser simple o fácil de entender por los diseñadores y por los usuarios finales. Esta propiedad y la expresividad son objetivos en conflicto; si un modelo es semánticamente rico, es probable que no sea simple.
3. Minimalidad: esta característica se consigue si ningún concepto presente puede expresarse por otros conceptos. Con la minimalidad se persigue que el modelo abstraiga lo esencial de la realidad, buscando la parsimonia.
4. Formalidad: todos los conceptos deben tener una interpretación única, precisa y bien definida.
Los modelos en la ingeniería del software, suelen describirse mediante representaciones lingüísticas y gráficas. El éxito de un modelo de datos depende en gran medida de su representación gráfica que debe ser lo más completa posible (si no requiere complementarse con una representación lingüística) y facilidad de lectura (si cada concepto se representa con un símbolo gráfico claramente distinguible del resto).
El modelo Entidad-Relación es el más usado para el modelamiento conceptual de bases de datos. Fue propuesto por Chen en 1976. En 1988, la ANSI seleccionó el modelo E-R como el modelo estándar para los sistemas de diccionarios de recursos de información (IRDS, Information Resource Dictionary Systems).
Posteriormente, el modelo fue extendido por otros autores, como Richard Barker en la metodología Case Method, para adicionar una mayor semántica.
En la figura siguiente, se aprecia un ejemplo de un diagrama entidad-relación, con la notación de Barker.
EMPLEADO DEPARTAMENTO # * carné * nombre * apellido o cargo * fecha enganche o salario o comisión # * número * nombre * ubicación jefe de subordinado de asignado a responsable de
• Entidad - representa una clase de objetos de la realidad, de la que se necesita mantener y conocer información.
• Relación - representa una conexión entre los objetos de una o más entidades.
• Atributo - representa una propiedad básica que caracteriza a una entidad o a una relación.
El modelo Entidad-Relación es un medio efectivo para recopilar y documentar los requerimientos en un formato claro y preciso. Esto es, un marco de especificación formal, fácil de entender por los usuarios finales, agilizando la comunicación entre éstos y los usuarios especialistas.
El modelo E-R (Entidad-Relación) se caracteriza, además, porque se puede refinar con facilidad. Proporciona un claro cuadro del alcance de los requerimientos de información y sirve de base de integración de múltiples aplicaciones, proyectos de desarrollo y paquetes comerciales.
Es importante establecer completamente los requerimientos de información de la organización durante la etapa de modelamiento para evitar cambios en etapas posteriores del desarrollo, pues siempre implican costos mayores que los que se detectan en una etapa temprana.
El modelo E-R puede ser transformado una base de datos jerárquica, en red, relacional u orientada por objetos e, incluso, a un ambiente tradicional de desarrollo de software. Esto es, puede ser traducido a cualquier modelo lógico que se desee.
8. ENTIDADES
Una entidad es una clase de objetos de importancia, en el dominio del problema, sobre la cual se debe guardar o conocer alguna propiedad. También puede definirse como una categoría. Ejemplos de entidades son: EMPLEADO
ARTICULO TIQUETE
Las entidades pueden ser simples si son irreducibles o complejas cuando están formadas, a su vez, por otras entidades.
Cada entidad se define por los atributos y sus relaciones que poseen. Por lo tanto, toda entidad debe poseer dichas propiedades. Algunos atributos posibles para la entidad EMPLEADO son: su fecha de vinculación, el salario y cargo.
Convenciones:
ü Para dibujar las entidades en el diagrama E-R se utilizan cajas, con bordes redondeados, de cualquier dimensión.
ü Cada entidad lleva un nombre único en mayúscula y en singular.
ü Puede ir un nombre sinónimo entre paréntesis. Los sinónimos son útiles cuando dos grupos de usuarios usan diferentes nombres para referirse a una misma entidad.
ü Los nombres de los atributos deben ir en minúsculas.
Ejemplos:
Cada entidad suele tener múltiples ocurrencias o instancias; es decir, debe tener asociada una población de objetos. Toda instancia tiene valores específicos para los atributos de la entidad.
Cada instancia debe ser identificable de las otras instancias u ocurrencias de la misma entidad. Un atributo o conjunto de atributos que identifican inequívocamente a cada instancia es llamado identificador único (IU).
Para los empleados, por ejemplo, el atributo cédula serviría como identificador único.
Los atributos que identifican a una entidad son marcados con el símbolo #. Para identificar y modelar las entidades de las notas de las entrevistas, se recomiendan los siguientes pasos:
PROYECTO # código ¯ nombre ¯ fecha de inicio ¯ fecha de finalización EQUIPO # referencia ¯ fabricante ¯ marca ¯ fecha de compra
1. Examinar los sustantivos presentes en la descripción verbal de los requerimientos de información. ¿Son cosas de importancia para considerarlos como entidades?
2. ¿Hay información de interés que se deba almacenar sobre esa entidad? 3. ¿Es identificable unívocamente cada instancia de esa entidad?
4. Elabore una descripción de cada entidad (será incluida en el diccionario de datos).
5. Dibuje la entidad y colóquele sus atributos.
No se debe descalificar una entidad muy rápidamente. Posteriormente, pueden surgir atributos de interés para la organización sobre esa entidad.
9. RELACIONES
Una relación es una asociación bidireccional, significativa, nombrable entre dos entidades, o de una entidad consigo misma. Cada relación asocia una instancia de cada una de las entidades involucradas en ella.
La sintaxis de una relación, permite una lectura:
debe una o varias
Cada entidad1 puede ser o estar nombre-relación una y sólo una entidad2
Ejemplo
La relación entre PROFESOR y CURSO es:
Cada CURSO puede ser dictado por uno y sólo un PROFESOR. Cada PROFESOR puede ser el docente de uno o más CURSOs.
Cada dirección de una relación tiene ciertas características que se pueden especificar en el modelo E-R:
• Un nombre - por ejemplo dictado por, asignado a
• Una opcionalidad (una cardinalidad mínima).
• Un grado o cardinalidad máxima.
Para dibujar las relaciones en el diagrama E-R, se siguen las siguientes convenciones:
• Los nombres de las relaciones se escriben en minúsculas y se colocan en los extremos de la línea de la relación.
• La cardinalidad mínima se representa con:
Si es obligatoria (debe ser o estar) Si es opcional (puede ser o estar)
• El grado o cardinalidad máxima se representa con:
Si la relación se puede dar con una o varias instancias de la otra entidad
Si la relación se puede dar sólo con una y sólo una instancia de la otra entidad
Si la cardinalidad, máxima o mínima, tiene una restricción numérica definida, se le agrega al extremo de la línea conectiva.
Una relación se lee primero en una dirección, y luego en la otra dirección.
Ejemplo
Para leer la relación entre EMPLEADO y DEPARTAMENTO:
EMPLEADO asignado DEPARTAMENTO
a
responsable de
Primero se leerá de izquierda a derecha:
“Cada EMPLEADO debe ser asignado a un, y sólo un, DEPARTAMENTO”. Ahora, si se lee de derecha a izquierda, sería como se muestra a continuación.
“Cada DEPARTAMENTO puede ser responsable de uno o varios un EMPLEADOs”.
• De muchos a uno (n:1) que se caracteriza por tener un grado de uno o
más en una dirección y un grado de uno y sólo uno en la otra dirección. Es una relación frecuente.
Ejemplo
TIQUETE comprado PASAJERO por
poseedor de
• De muchos a muchos (n:m) que tienen un grado de uno o más en ambas direcciones. También es una relación muy común.
Ejemplo
ARRENDADOR generador ALQUILER
de
originado por
• Uno a uno (1:1) tiene un grado uno y sólo uno en ambas direcciones. Este tipo de relaciones es rara. Es importante tener cuidado ya que puede que una relación de éstas entre entidades sea realmente una misma entidad.
OPERARIO encargado de manejada por MAQUINA
Todas las entidades, relaciones y atributos deben representar los requerimientos de información y las reglas de la organización.
10. MATRIZ DE RELACIONES
Como ayuda inicial en la recolección de la información acerca de las relaciones entre un conjunto de entidades se emplea la matriz de relaciones. Una matriz de relaciones muestra para cada entidad fila sobre el lado izquierdo si tiene una relación y cómo es ésta, con cada entidad columna. Todas las entidades son listadas tanto en el lado izquierdo como en la parte superior de la matriz. Si una entidad fila tiene una relación con una entidad
columna, entonces se coloca el nombre de la relación en la celda que las intercepta. Si no existe una relación se coloca una raya horizontal.
Cada relación encima de la diagonal es la inversa o el espejo de una relación por debajo de la diagonal. Las relaciones recursivas (de una entidad consigo misma) se representan sobre la línea diagonal.
Ejemplo
La siguiente matriz muestra las relaciones entre cuatro entidades.
CLIENTE ARTICULO ORDEN BODEGA
CLIENTE el generador de ARTICULO comprado mediante almacenado en ORDEN Hecha para Compuesta de
BODEGA sitio de
almacenamiento
Una vez se tengan definidas las relaciones en la matriz, se pueden llevar al modelo entidad-relación.
ARTICULO código descripción BODEGA identificador dirección ORDEN número fecha CLIENTE identificador dirección razón social almacenado en el repositorio de comprado por compuesta de originada por el originador de
Debemos leer en voz alta las relaciones para validarlas y emplear la matriz de relaciones para examinar si existe una relación entre cada pareja de entidades.
No se deben usar los términos "relacionado con" o "asociado a" como nombres de relaciones, pues estos nombres no definen cuál tipo de relación se está modelando.
11. LOS ATRIBUTOS
Los atributos son información que se necesita conocer y mantener de una entidad. Sirven para describir, identificar, cualificar, clasificar, cuantificar o expresar un estado de una entidad.
Los atributos representan un tipo de descripción o detalle, no una instancia; los nombres dados a los atributos deben ser claros para el usuario y no deben incluir el nombre de la entidad; ya que sería redundante como en el caso de colocar código de curso en la entidad CURSO.
Los nombres de los atributos deben ser específicos y completos. Esto es,
cantidad comprada, fecha de envío en vez de, únicamente, cantidad y fecha. Las convenciones que rigen para representar los atributos en diagrama E-R, señalan que siempre deben ir en singular y en minúscula y se colocan dentro de la caja de la entidad
Se debe descomponer un atributo hasta aquella componente mínima con significado propio. Así, el nombre de una persona debe ser descompuesto en nombre y apellidos. Los atributos que contengan fechas no se
descomponen. No obstante, el nivel de descomposición dependerá de las necesidades organizacionales.
Se debe verificar que cada atributo tenga un solo valor para cada instancia de la entidad; pues un atributo con múltiples valores o grupos que se repiten no son un atributo válido, en este modelo.
Para representarlos, entonces, es necesario ascenderlos a la categoría de entidad.
Ejemplo
En ESTUDIANTE, el atributo notas es multivaluado: ESTUDIANTE carné nombre apellido notas carrera
Entonces, es preciso crear promover el atributo notas a la categoría de clase y establecer una relación con estudiante.
Se debe verificar que un atributo no sea calculado o derivado de los valores existentes de otros atributos. El atributo derivado es redundante y las redundancias pueden conducir a inconsistencias en los valores de los datos. Algunas veces se necesita, por cuestiones de eficiencia, tener datos redundantes; pero se debe tener muy presentes en la etapa de diseño para que sean, en la medida de lo posible, calculados o recalculados (en el caso de correcciones) automáticamente por el sistema.
Si un atributo tiene, a su vez, atributos propios; entonces debe modelarse como otra entidad.
COMPUTADOR referencia marca tarjeta madre fecha de compra COMPUTADOR referencia marca TARJETA MADRE fecha de compra número serie chip procesador velocidad procesador chip coprocesador para poseedora de
Existen atributos obligatorios y otros que pueden ser opcionales. El atributo obligatorio significa que en todo momento es importante conocer el valor que toma para cada ocurrencia de la entidad y se marcan con un asterisco. Cuando el atributo es opcional se marca con la letra “o”.
Ejemplo PERSONA * código * nombre o profesión * sexo o peso 12. IDENTIFICADORES UNICOS
Un identificador único (IU) puede ser cualquier combinación de atributos y/o relaciones que sirven para identificar inequívocamente una ocurrencia de una entidad. Cada instancia debe ser completamente identificable.
Puede ocurrir que una entidad sea identificada por medio de una relación. En las corporaciones financieras, por ejemplo, a cada sucursal se le asigna un número de identificación y dentro de ellas, cada cuenta tiene un número único. Entonces, una CUENTA se identifica completamente con su número más el número de la sucursal.
Observe cómo, en este caso, se coloca una barra para indicar que la relación forma parte del identificador único.
Una relación parte de un Identificador Unico debe ser obligatoria y de grado
uno y sólo uno en la dirección que participa en la identificación única.
No es raro, tampoco, que una entidad sea identificada por varias relaciones. Ejemplo
Para diferenciar una inscripción a un curso de otra, se necesita el carné del estudiante, el código del curso y de la fecha de inscripción
INSCRIPCION ESTUDIANTE CURSO # * carné * nombre * nombre # * código # * fecha de registrado en para motivo para o nota definitiva
Una entidad puede tener más de un identificador único. Este es el caso de un estudiante que posee un carné y un documento de identificación (cédula o T.I)
Se debe seleccionar uno, entre los candidatos, para que sea el identificador único y los otros se dejan como UI secundarios; aunque, lastimosamente, no se muestran los identificadores únicos alternos en el modelo E-R.
En ocasiones, se usan identificadores artificiales (como pasa en la realidad) para ayudar en la diferenciación rápida de las instancias de una entidad.
ARTICULO * descripción * unidad de medida * cantidad a la mano * precio de venta * marca
Para identificar los artículos que vende una tienda, se necesitaría de la descripción del artículo, de la unidad de medida y de la marca. Para evitar un identificador único tan largo, es mejor crear un código artificial que será único para cada instancia.
13. La normalización
La normalización es un concepto de bases de datos relacionales, pero sus principios se pueden aplicar desde la etapa del modelamiento conceptual. La ubicación de los atributos se valida, usando las reglas de normalización La primera forma normal (1FN) determina que todos los atributos deben poseer un sólo valor (ser atómicos).
La segunda forma normal enuncia que todo atributo debe ser dependiente del identificador único de la entidad a la que pertenece.
La tercera forma normal dice que ningún atributo que no sea identificador único puede depender de otro que tampoco lo sea.
Lo que se persigue con la normalización es evitar redundancia de datos y, por ende, posibles inconsistencias.
Hasta la tercera forma normal generalmente se acepta que se normalice.
Regla de la primera forma normal: todos los atributos deben poseer un sólo valor.
Revise que ningún atributo tenga más de un valor para cada instancia de una entidad. Ejemplo PACIENTE # * identificación * nombre * dirección * teléfono * fechas citas
El atributo fechas de las citas porque tiene múltiples valores. Por lo tanto, la entidad PACIENTE, no está en primera forma normal debemos crear una nueva entidad CITA MEDICA con una relación uno a muchas con PACIENTE.
CITA MEDICA en para PACIENTE # * número # * identificación * nombre * dirección * teléfono * fecha figura
SOLUCION: Si un atributo tiene múltiples valores, cree una entidad adicional y relaciónela con la original con una relación n:1.
Regla de la segunda forma normal: todo atributo debe ser dependiente del identificador único de la entidad a la que pertenece.
Para validar si entidad cumple con la segunda forma normal, verifique que cada identificador único específico determine una sola ocurrencia para cada atributo. Asegúrese de un atributo no dependa únicamente de una parte del IU de esa entidad.
Ejemplos
1. Valide si PACIENTE está en segunda forma normal
PACIENTE # * identificación
* nombre * dirección * teléfono
Cada instancia una identificación de paciente determina un valor específico para nombre, dirección y teléfono. Entonces los atributos están bien ubicados.
2. Valide la ubicación de los atributos para las entidades
CUENTA de manejada BANCO # * número # * número * nombre * fecha apertura administrador
* localización
En el ejemplo anterior, cada instancia de BANCO y de un número de cuenta determinan una fecha específica de apertura. El atributo localización está mal ubicado. Depende del BANCO pero no del número de la cuenta. No debería ser, entonces, atributo de cuenta.
SOLUCION: si un atributo no depende del identificador único entero, está mal ubicado y debe ser movido a otra entidad.
Regla tercera forma normal: ningún atributo que no sea identificador único puede depender de otro que tampoco lo sea.
Ejemplo
Verifique si algún atributo no IU depende de cualquier otro que tampoco es IU # * número * codigo editorial REVISTA * nombre editorial * fecha publicación
El atributo nombre de la editorial depende de otro que no es identificador único: código de la editorial. Luego, se debe crear una nueva entidad EDITORIAL y se reubican los atributos.
# número # codigo REVISTA * nombre * fecha publicación EDITORIAL editada por editora de
Solución: si un atributo no IU depende de otro que tampoco es IU, mueva ambos a una nueva entidad relacionada con la original.
Resolución de las relaciones de muchos a muchos (n:m)
Una relación de este tipo no debe aparecer en el modelo E-R. Una relación de muchos a muchos se resuelve adicionando una entidad de intersección.
Considere una relación muchos a muchos entre COMPAÑÍA DE SEGUROS y SINIESTRO.
El valor del seguro y la fecha de vencimiento del mismo, son atributos de la relación entre SINIESTRO y COMPAÑÍA DE SEGUROS. Los atributos sólo describen a las entidades.
Si los atributos describen una relación, entonces ésta debe ser resuelta. Se resuelve una relación n:m con una entidad nueva de intersección y dos relaciones 1:n.
Para el ejemplo, se puede adicionar la entidad de intersección POLIZA.
de ASEGURADORA # código # código * nombre encargada de SINIESTRO * nombre * dirección # número POLIZA * fecha inicial * fecha vencimiento * valor asegurado amparado con registradora de
En efecto, los atributos valor del seguro, la fecha inicial y de vencimiento pertenecen a la entidad POLIZA.
Para resolver una relación muchos a muchos, se ubica la entidad de intersección de tal manera que las patas de gallina siempre se dirijan hacia la izquierda o hacia arriba en el diagrama:
SINIESTRO # Código * Nombre COMPAÑIA DE SEGUROS # Número * Nombre
entidad de intersección
entidades de referencia
o así
El identificador único de una entidad de intersección casi siempre está compuesto por las relaciones de las dos entidades que le dieron origen. Ejemplo CURSO ESTUDIANTE # código * nombre * créditos * duración * nombre * teléfono tomado por inscrito en # carné
Para resolver la relación de muchos a muchos, adicionamos la entidad de intersección INSCRIPCION y dos relaciones 1: m.
CURSO ESTUDIANTE # código * nombre * créditos * duración * nombre * teléfono
tomado via registrado en
# carné para de INSCRIPCION * fecha iniciación * fecha culminación * nota definitiva
Una vez se identifique la entidad de intersección, se deben buscar atributos adicionales que la describan. Puede ocurrir, sin embargo, que obtengamos una entidad de intersección sin atributos; en este caso tendremos sólo una referencia cruzada entre las ocurrencias de las entidades y el identificador único para la entidad de intersección, estará siempre compuesto de las relaciones de las dos entidades de las cuales se originó.
Una entidad de intersección sin atributos es la excepción a la regla de que una entidad siempre debe poseer atributos para poder ser, realmente, una entidad. Ejemplo ACTOR PELICULA # código * nombre artistico o nombre real o fecha nacimiento * nombre * clasificación protagonista protagonizada # identificador de por
Para esta relación de muchos a muchos, no se identifican atributos asociados. Entonces, se resuelve con una entidad de intersección sin atributos. ACTOR PELICULA # código * nombre artistico o nombre real o fecha nacimiento * nombre * clasificación # identificador PAPEL ESTELAR poseedor de de figurar con en 14. Relaciones jerárquicas
Los identificadores únicos para un conjunto de entidades con una relación de jerarquía se pueden propagar a través de múltiples relaciones como se ilustra en el siguiente ejemplo.
APARTAMENTO # número situado en conformado por PISO BLOQUE * propietario # número # número UNIDAD # código * nombre * dirección situado en situado en conformado por conformado por
El IU de APARTAMENTO es el número del apartamento y del PISO donde se localiza.
El IU de PISO es el número del piso y del BLOQUE donde se localiza.
El IU de BLOQUE es el número del bloque y del código de la UNIDAD donde se localiza.
Cuando las estructuras jerárquicas cambian a menudo, es mejor crear atributos artificiales para ayudar a identificar las entidades.
15. Relaciones recursivas
Ejemplo EMPLEADO # cédula * nombre o profesión * cargo * fecha ingreso * salario a cargo de bajo ordenes de
La convención para dibujar una relación recursiva es conocida con el nombre de “cola de marrano”. Puede aparecer en cualquier lado de la caja de la entidad; pero recordando que el lado de muchos siempre va hacia la izquierda o hacia arriba.
Es recomendable representar una relación jerárquica como una recursiva: APARTAMENTO # número situado en conformado por PISO BLOQUE * propietario # número # número UNIDAD # código * nombre * dirección situado en situado en conformado por conformado por # código o nombre o dirección LOCALIZACION dentro de conformada por o propietario
La entidad recursiva debe incluir todos los atributos de cada entidad individual. La relación recursiva debe ser siempre opcional en ambas direcciones; puesto que la jerarquía sería infinita.
16. Generaciones de Bases de Datos
El origen del primer DBMS ocurre a mediados de los años sesenta cuando IBM y Rockwell International desarrollaron las primeras versiones de un sistema conocido como DL/I con el propósito de administrar la gran cantidad de datos del proyecto espacial APOLO [GON96]. Posteriormente, le adicionan una componente de control de la información, en el sistema (ICS) para el acceso a los datos en forma concurrente.
El anterior producto se comercializa en 1969, bajo el nombre de IMS/360 (Information Management System para el IBM 360).
Los sistemas manejadores de bases de datos, DBMS, se pueden clasificar por el método empleado para estructurar los datos internamente. A las estructuras de datos utilizadas se les llaman también modelos físicos de datos.
El IMS es un DBMS de tipo jerárquico, es decir, se sustenta sobre una estructura de datos jerárquica o de árbol; en donde los nodos representan las entidades y los arcos representan las relaciones.
La arquitectura del IMS se muestra en la figura 3.
Figura 3. Arquitectura del DBMS Jerárquico IMS/360.
Aplicación 2 Programa de comunicación Aplicación 1 Aplicación n Programa de comunicación Programa de comunicación
Las descripciones de la base de datos, definen una base de datos física que agrupa la información sobre todos los segmentos (que representan las entidades) con su longitud y clave, entre otras cosas.
El programa de comunicación define el mecanismo usado para el paso del modelo lógico al físico.
Finalmente, cada aplicación define el conjunto de procedimientos y de funciones que requiere un usuario final.
Los desarrolladores de bases de datos jerárquicas se referían a las relaciones 1:n, como relaciones “padre-hijo” entre los registros; que se podían implementar por medio de adyacencia física (registro padre + arreglo de registros hijos) o por medio de punteros. Las bases de datos jerárquicas se construyen reuniendo múltiples relaciones padre-hijo.
La figura 4, muestra una estructura de árbol cuyo nodo raíz, es Asignatura. ASIGNATURA
REQUISITOS CURSOS
PROFESORES ESTUDIANTES
Figura 4. Estructura de una base de datos académica.
El problema básico de la estructura jerárquica, consistió en que un registro hijo no podía tener dos registros padres distintos. Esta situación impedía representar relaciones muchos a muchos, sin tener redundancia.
Considere, por ejemplo, las relaciones siguientes (ver figura 5): Un estudiante puede matricularse en varios cursos (relación 1:n) Un curso puede ser tomado por varios estudiantes (relación 1:n)
Código Descripción
Fecha Grupo Aula
Si se quisiera generar el certificado del registro académico de un estudiante, se tendría que usar la primera relación. Si se quisiera generar la lista de estudiantes matriculados en un curso dado, se tendría que usar la segunda relación. El modelo jerárquico obliga a repetir información para dar respuesta a estos dos tipos de consultas.
Figura 5. Una relación n: m
Segunda Generación de Bases de Datos
Para resolver el problema de la redundancia en las bases de datos jerárquicas, con las relaciones de muchos a muchos, surgen las bases de datos en red. La estructura de un DBMS en red es esencialmente la misma que en el modelo de datos jerárquico; excepto que un “miembro” (registro hijo) puede pertenecer a más de un “conjunto” (registro padre).
Los DBMS en red son más generales que un DBMS jerárquico; pues un árbol siempre podrá ser una red, en cambio una red puede no ser un árbol. Las redes de conjuntos de una base de datos siempre son implementadas mediante punteros, como lo ilustra la figura 6.
Figura 6. Una instancia de Conjunto
A pesar de superar el problema de la redundancia de datos, se originó otro relacionado con el manejo de punteros; pues además de aumentar la complejidad, las relaciones que se creaban por medio de ellos hacían que
ESTUDIANTE CURSO
REGISTRO
123 | Juan Pérez
registro 128 registro 145
se tuviera definir de antemano cómo se consultarían los datos; restando flexibilidad a los sistemas.
TERCERA GENERACION DE BASES DE DATOS
En 1970, E.F. Codd de la IBM propone el modelo relacional que está basado en la teoría de conjuntos y en la lógica de predicados de primer orden. La idea de Codd consistía en evitar el uso de punteros por parte de los usuarios especialistas para facilitar la gestión de los datos y sus relaciones; el DBMS se debería encargar del manejo de los punteros de las estructuras de datos físicas. La técnica consistía en representar los datos como tablas bidimensionales; una manera mucho más sencilla y comprensible y por ello, este modelo de datos logró la popularidad que hoy sigue teniendo.
Codd encontraba otro problema básico de los modelos primitivos, además del manejo de punteros, que era la restricción de procesar sólo un registro a la vez y por ello el usuario debía controlar condiciones como "fin de archivo". En lugar de ello, él quería que se pudiera realizar operaciones sobre conjuntos de datos y que el DBMS controlara los detalles o las condiciones para llevar a cabo estas operaciones.
Ventajas del modelo relacional
1. Separación clara del nivel lógico y el físico. El usuario no ve para nada el nivel físico.
2. Simple y fácil de trabajar con él. La representación de los datos por tablas es intuitiva pues recuerda las hojas electrónicas.
3. Operadores poderosos para la manipulación de datos. 4. Fundamentos teóricos sólidos.
Desventajas:
1. La eficiencia se ve afectada por la prohibición de manejo de punteros en forma explícita; aunque en algunos manejadores de bases de datos se puede tener acceso a los objetos mediante su ROWID.
Terminología
Antes de explorar el modelo relacional es importante dar la definición de los conceptos básicos que éste incluye.
Relaciones y Tablas
La estructura básica del modelo relacional, y de ahí su nombre, es la relación. El término relación es tomado de la teoría de conjuntos y no tiene que ver para nada
con el hecho de que los datos puedan estar relacionados. Una relación es un concepto abstracto de un estructura bidimensional. Una relación se puede definir por comprensión o por extensión. Así, por ejemplo, podemos definir por comprensión la relación R:
R = { x / x(identificación, nombre, telefono) es estudiante de la Universidad Nacional }
La estructura bidimensional que asociamos familiarmente a una relación es la tabla, entonces estos dos términos se usan indistintamente.
Una relación en este modelo tiene las siguientes propiedades:
• Cada celda es atómica o univaluada
• Cada columna tiene un nombre único dentro de la tabla • El orden de las columnas o filas es indiferente.
• Cada fila es distinta e identificable por alguna combinación de sus valores
en los atributos.
Tuplas, Atributos y Cardinalidad
Cada instancia o fila de una relación se le denomina tupla ya cada columna se le denomina también atributo. Al número de atributos se le denomina el grado de una relación y al número de tuplas se le denomina cardinalidad o extensión de la relación.
Dominio
Un dominio es un conjunto aceptable de valores para un atributo. Un dominio puede ser compartido por varios atributos y se puede restringir para velar por la integridad de la base de datos.
Clave Primaria
Las claves sirven para la identificación de las tuplas. Se utiliza, entonces, una colección mínima de atributos como clave primaria para representar los identificadores únicos del modelo E-R.
Atributo (columna) o atributos que identifican a una tupla (fila) dada. La clave primaria es la clave candidata elegida por el DBA.
Clave foránea:
Es un atributo que es clave primaria en otra relación. Permite explícitamente especificar las relaciones entre dos diferentes tablas y es también un mecanismo para asegurar la integridad.
Terminología Alternativa de términos
Relacional Común Sistemas de Archivos Relación Tabla Archivo
Tupla Fila Registro
Atributo Columna Campo Instancia Valor Valor
DISEÑO DE BASES DE DATOS
El diseño de la base de datos se realiza durante la etapa de diseño del sistema y se hace al tiempo con el diseño de la aplicación de las aplicaciones que se piensen desarrollar, en paralelo.
El diseño, produce especificaciones para la implementación de bases de datos relacionales; incluyendo definiciones para las relaciones, los índices, las vistas que se deben crear y otras especificaciones sobre el espacio de almacenamiento. Se debe documentar el sistema, con una tabla de especificaciones para cada relación en el modelo relacional.
Tabla de Especificación de la Relación EMPLEADOS
Nombre Columna
EMPNO NOMB APELL TBJO FCHING SAL JEFE DEPNO
Tipo de Clave CP CF1 CF2 Nulos/ Unicos NN, U NN NN NN NN
Ejemplos 7369 Pedro Hoyos Dependiente 17-12-80 800 7902 20
7902 Ana Casas Analista 03-12-81 3000 7566 50
• Los tipos de clave válidos, son CP para una columna de clave primaria, y CF
• Se usan sufijos para distinguir entre múltiples columnas de CF en una tabla
simple, por ejemplo, CF1 y CF2. Se rotulan múltiples columnas clave con el mismo sufijo.
• Se usa el rótulo NN para las columnas que deben ser definidas como no
nulas (NOT NULL).
• Se usa el rótulo U para una columna que deba ser única (unique).
• Si varias columnas deben ser únicas en combinación, se nombran con sufijos,
por ejemplo U1.
• Se designa una columna simple que es clave primaria como NN, U.
• Se designan múltiples columnas CP como NN, U1 o posiblemente como NN,
U1, U.
El modelo E-R de una institución de educación no formal que se observa en la figura número 1, se empleará para ilustrar como transformar el modelo E-R en un modelo relacional.
para
tomado por medio de
de dictado por
registrado con instructor de
Figura 7 Modelo E_R de una institución educativa
Se siguen una serie de pasos para transformar el Modelo E-R a una serie de relaciones, produciendo un diseño inicial de la base de datos.
PASO 1 - CONVERTIR LAS ENTIDADES SIMPLES A RELACIONES INSCRIPCION * Fecha inscripción o Fecha finalización o Nota CURSO # Código * Nombre o Cuota o Duración ESTUDIANTE # Identificación * Nombre * Apellido * Teléfono PROFESOR # Identificación * Nombre * Apellido oTeléfono oficina
Las entidades simples, entidades que no son subtipos o supertipos, ni participan en una relación exclusiva en el modelo E-R, se transforman en relaciones del modelo relacional.
Se crea una tabla de especificación para cada entidad simple. Inicialmente se comienza con el nombre que se le va a dar a esta entidad en el modelo relacional. El nombre de la tabla debe permitir recordar el nombre de la entidad. Se acostumbra a utilizar el plural del nombre de la entidad para el nombre de la relación en el modelo relacional, en especial si éste no es largo.
PASO 2 - CONVERTIR LOS ATRIBUTOS A COLUMNAS
Cada atributo se vuelve una columna de la relación a la cual pertenece. Se debe especificar que los atributos requeridos son columnas NOT NULL (NN).
Ejemplo: Como los atributos identificación, nombre y apellido son atributos de entrada obligatoria de la entidad PROFESOR, se transforman en columnas no nulas. Se debe, entonces, designar sus columnas como NOT NULL.
PROFESOR
Nombre Columna
ID_PROF NOMB APELL TEL
Tipo de Clave Nulos/ Unicos NN NN NN Ejemplos
Para cada atributo, se sugiere seleccionar un nombre de columna corto pero significativo. El nombre de la columna debe ser fácil de recordar. Es bueno utilizar abreviaturas consistentes para evitar confusión al programador y al usuario. Por ejemplo, Número será abreviado como NO o NUM. Esto es, NODEPTO o NUMDEPTO?
Los nombres de las columnas cortos reducen el tiempo requerido para la ejecución de comandos del SQL. Para determinar los tipos de datos adecuados es útil documentar las tablas de especificaciones, con tuplas ejemplo.
Los datos ejemplo, se pueden obtener de diversas maneras:
• De notas de entrevistas con los usuarios finales.
• De la documentación de sistemas informáticos actuales. • De conversaciones adicionales con el usuario.
PASO 3 - CONVERTIR LOS IDENTIFICADORES UNICOS A CLAVES PRIMARIAS
En este paso, cada atributo que hace parte de los identificadores únicos de la entidad se convierten en columnas con tipo de clave primaria (CP).
• Todas las columnas CP deben ser también NN y U.
• Un identificador único que incluya varios atributos, se convierte en una clave
primaria compuesta. Estas columnas son NN y U1.
Si el identificador único, IU, de una entidad incluye una relación, se deben añadir las columnas de las claves foráneas a la tabla y marcarlas como parte de la clave primaria.
Ejemplo: el identificador único de la entidad INSCRIPCION está compuesto por las relaciones con las entidades CURSO y ESTUDIANTE. Por lo tanto, es necesario añadir dos columnas claves foráneas, a la tabla INSCRIPCION, para formar su clave primaria.
Tabla: INSCRIPCION
Columna FCH_INS FCH_FIN NOTA COD_CUR ID_EST
Tipo Clave CP, CF1 CP, CF2 Nulos/ Unicos NN NN, U1 NN, U1 Ejemplos 20/08/98 29/09/98 --- 344 47593 05/06/98 --- --- 401 15402 14/06/98 28/06/98 4.1 717 51394 08/05/98 28/06/98 4.2 717 94572 05/05/98 21/05/98 4.0 401 51394
• Escoger un nombre único para cada columna CF, y rotular la(s) columna(s)
CP, NN y CF.
• Si existen múltiples columnas CF en la tabla, usar sufijos para distinguir entre
ellas, por ejemplo, CF1 y CF2. Debemos rotular varias columnas claves con el mismo sufijo
• Una CP compuesta debe ser única en combinación y se debe rotular como
U1.
Para una relación 1:n, se debe tomar el IU de la entidad con cardinalidad de uno y ponerla en la tabla relacional que corresponde a la entidad con cardinalidad de muchos.
Por ejemplo, se toma la clave primaria Identificación en el lado de uno, y se coloca en la relación CURSO que está en el lado de "muchos".
instructor de dictado por Tabla: CURSO Nombre Columna
COD_CUR NOMBRE CUOTA DUR ID_PROF
Tipo de Clave CP CF Nulos/ Unicos NN, U NN Ejemplos 344 SQL SERVER 1000 5 81 974 ORACLE 400 2 73 401 DISEÑO BD 400 2 95 717 TAREAS DE UN DBA 900 3 73
• Se debe seleccionar un nombre único para la columna CF y rotularla como
CF.
• Para relaciones obligatorias también se debe especificar que la columna es no nula, NN.
Para una relación 1:1 obligatoria, se debe colocar la clave foránea única en la tabla al lado de la obligatoriedad y usar la restricción de NOT NULL para hacer cumplir la relación de obligación.
Ejemplo: la relación entre COMPUTADOR PERSONAL y TARJETA MADRE ES UNA RELACIÓN 1:1 y es obligatoria hacia tarjeta madre. Entonces, se coloca la clave foránea de la relación en la tabla COMPUTADOR PERSONAL y se rotula
CURSO #Código * Nombre o Cuota o Duración PROFESOR # Identificación * Nombre * Apellido oTeléfono oficina
como NOT NULL. ID_TM es la clavbe foránea añadida. Esta columna también se rotula como U para hacer cumplir la relación 1:1.
COMPUTADOR_PERSONAL TARJETA_MADRE Nombre Columna NO_ INV TIPO_ CASE FTE_ ENER ID_TM Nombre Columna ID_TM CHIP_ PRO VEL_ PRO CHIP_ COPR
Tipo Clave CP CF Tipo Clave CP
Nulls/ Unique
NN, U NN NN NN, U Nulls/
Unique
NN, U NN NN NN
Datos de 1045 Baby AT 150 4579 Datos de 9978 486 33 N
Prueba 0437 Baby AT 200 8731 Prueba 4517 386 40 S
1458 Tower 220 4773 4773 486 25 N
1223 Tower 220 9978 4579 386SX 25 N
1088 Minitower 200 4517 8731 386 33 S
La clave foránea en una relación 1:1 siempre debe ser única, pero puede permitir valores nulos, en algunos casos.
Si una relación 1:1 es opcional en ambas direcciones, se puede colocar la clave foránea en la tabla que corresponda a cualquier entidad participante en la relación.
Cuando exista una relación recursiva 1:n, se debe adicionar una columna CF a la tabla simple. Esta columna CF remitirá a los valores de la columna CP.
Ejemplo: Para esta relación recursiva 1:M, añadir una columna CF a la tabla EMPLEADO por cada Jefe de empleado. Nombrar la columna ID_JEFE para reflejar la relación. jefe de bajo órdenes de Tabla: EMPLEADO Nombre Columna
ID_EMP NOMBRE APELL ID_JEFE
EMPLEADO #*Id
*Nombre *Apellido
Tipo de clave CP CF
Nulos/ Unicos
NN, U NN NN
Ejemplos 7450 María Pérez
---5579 Juana Mejía 7450 6714 Susana Jiménez 5579
Se debe observar que la columna CF se refiere a una fila en la misma tabla. La columna CF se nombra de tal manera que refleje la relación.
Debe observarse, además, que una CF recursiva nunca será NOT NULL porque se crearía un ciclo infinito.
Para una relación recursiva 1:1, es necesario añadir una clave foránea única a la tabla. Esta columna CF remitirá a los valores de la columna CP.
Ejemplo: Para la relación recursiva 1:1 "casado(a) con", se agregó una columna única, a la tabla PERSONA.
esposo(a) de casado(a) con Tabla: PERSONA Nombre Columna
ID_PERS NOMBRE APELL ID_ESP
Tipo de Clave CP CF
Nulos/Unicos NN, U1 NN NN U1
Ejemplo 7450 María Pérez
---5579 Juana Gómez 9451 6714 Susana Jiménez 3040 9451 Raúl Tobón 5579 3040 Diego García 6714
• La combinación de las columnas CF y CP siempre debe ser únicas para
asegurar la relación 1:1. Se garantiza que la combinación sea única rotulándolas ambas columnas como U1.
PASO 5 - ESCOGER OPCIONES DE ARCO
PERSONA #*Id
*Nombre *Apellido
Figura 8 . Relación exclusiva
Los arcos representan una clase de clave foránea con varias alternativas. Se escoge entre dos diseños para llevar los arcos a claves foráneas:
• Diseño de Arco Explícito • Diseño de Arco Genérico
El diseño de Arco Explícito crea una columna, clave foránea, para cada relación incluida en el arco.
Así, porel ejemplo, el modelo E-R de la figura número 2, el arco se extiende sobre el final de tres relaciones de "muchos". Entonces, se deben adicionar tres claves foráneas a la relación de OFICINAS:
OFICINAS
Nombre Columna
ID_EDIF NO_OFIC ID_IND COD_SOC NO_COMP
Tipo de Clave CP CP CF1 CF2 CF3
Valores nulos/únicos
NN, U1 NN, U1
El diseño de Arco Explícito soporta múltiples claves foráneas con diferentes formatos. Por ejemplo, ID_IND, COD_SOC y NO_COMP pueden tener diferentes formatos de columna.
Sin embargo, con este tipo de diseño, la aplicación debe hacer cumplir la exclusividad de la relación entre las claves foráneas.
El diseño de arco genérico, por otro lado, crea una columna de clave foránea simple y una columna adicional utilizada para indicar cuál de las tablas es referenciada por la columna clave foránea en cada fila. Como las relaciones son exclusivas, solamente existe un valor de la clave foránea por cada fila en la tabla.
INDIVIDUAL #*Id SOCIEDAD #*Código COMPAÑIA #*Número INDIVIDUAL #*Id SOCIEDAD #*Código COMPAÑIA #*Número SOCIEDAD # Código COMPAÑIA # Número OFICINA #*Id edificio #*Número oficina OFICINA #*Id edificio #*Número oficina OFICINA
Usando el diseño de arco genérico, con el ejemplo, se debe crear una columna de clave foránea simple y añadir una columna de tipos para indicar cuál de las tres tablas es la referenciada en cada fila. Por ejemplo, I por INDIVIDUO, S por SOCIEDAD y C por COMPAÑIA.
OFICINAS
Nombre Columna
ID_EDIF NO_OFIC ID_RENTADOR TIPO_RENTADOR
Tipo de Clave CP CP CF
Valores nulos/únicos
NN, U1 NN, U1 NN NN
Ejemplos 1024 101 30045 I
Si la relación bajo el arco es obligatoria, se deben definir todas las columnas añadidas como NOT NULL.
Con este tipo de diseño, las claves foráneas deben compartir el mismo formato en todas las tablas de referencia y la relación de exclusividad queda asegurada automáticamente.
PASO 6- ESCOGER OPCIONES PARA LAS RELACIONES SUPERTIPO/SUBTIPOS
Las opciones posibles, son las siguientes:
• Diseño de los subtipos, en una sola tabla (el supertipo). • Diseño de los subtipos en tablas separadas.
• Como un arco de una relación exclusiva.
Opción 1 - Diseño de los subtipos en una sola tabla.
EMPLEADO # Número * Nombre * Apellidos DE PLANTA *Salario TEMPORAL * Valor hora * Valor hora extra
DEPARTAMENTO #*Código
EMPRESA # nit
Consiste en diseñar una tabla para el supertipo con toda la información de los subtipos. Es decir, la tabla resultante contendrá las instancias de todos los subtipos.
Este diseño es apropiado cuando los subtipos tienen pocos atributos y relaciones propias y la consulta de los datos suele incluir datos de distintos subtipos.
Pasos de diseño
• Crear una tabla para el supertipo
• Crear una columna TIPO para identificar a cuál subtipo pertenece cada fila. • Crear una columna para cada uno de los atributos del supertipo.
• Crear una columna para cada uno de los atributos de los subtipos. • Crear columnas CF para cada una de las relaciones del supertipo. • Crear columnas CF para cada una de las relaciones de los subtipos.
Como ejemplo, se convertirá el supertipo EMPLEADO y sus subtipos de la figura 3, en una sola tabla.
EMPLEADO
Nombre Columna
NUM NOMB APELL TIPO SALARIO VLR_ HORA VLR_ EXTRA NUM_ EMP COD_ DEP Tipo de Clave CP CF1 CF2 Nulos/ Unicos NN, U NN NN NN NN
Ejemplos 4579 Jaime Pérez P 29000 40
6631 Ana Casas P 25000 35 1190 Juan Hoyos P 42700 40 370 Pedro Díaz P 44050 30 800 Luis Ruiz P 38450 35 7147 Alex Ríos T 8.50 12.75 201 35 6794 Lili Vega T 6.75 11.50 150 30
El diseño de en una sola tabla requiere siempre que se cree una nueva columna (tipo) para identificar el subtipo correspondiente en cada fila.
Ventajas de este diseño
• El acceso al supertipo es directo. Si en la organización se debe consultar
frecuentemente el supertipo, esta opción es apropiada.
• Se puede tener acceso a los subtipos mediante vistas.
