tabla de contenido 1. breve historia de las ......tabla de contenido 1. breve historia de las bases...

TABLA DE CONTENIDO

1. BREVE HISTORIA DE LAS BASES DE DATOS 3

2. QUE ES UNA BASE DE DATOS? 6

3. LA INFORMACIÓN COMO RECURSO CORPORATIVO 3Ventajas 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

16. GENERACIONES DE BASES DE DATOS 38

1. Conceptos Básicos

C l a u d i a J i m é n e z R a m í r e z B a s e s d e D a t o s 3

LA INFORMACIÓN COMO RECURSOCORPORATIVO

En los últimos tiempos, se ha empezado a considerar la información comoun recurso estratégico de una organización; pues le facilita su supervivenciay le permite, además, ser competitiva en el mercado. También le permiteanticiparse a los cambios futuros y adaptarse mucho más rápidamente aellos.

De la información que una organización almacene y de cómo estéorganizada esta información, dependen cuáles preguntas se puedenformular acerca de su gestión actual o pasada, tanto internamentecomo en el entorno.

El tratamiento estadístico con datos históricos es factor clave en elfuturo de la organización y vital en su planeación.

La calidad y oportunidad de las decisiones a todos los nivelesdepende en gran medida de hacer llegar la información correcta en elmomento adecuado, a las personas que la necesitan.

La información se debe considerar como otro recurso corporativo de lamisma 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 parasobrevivir es cada vez mayor. Para ello, deben existir métodos eficientestanto para el almacenamiento rápido como para la consulta ágil. Latecnología que actualmente es más utilizada para manejar grandesvolúmenes de datos es la tecnología de Bases de Datos.


En los inicios de la computación se elaboraban programas de computador alos cuales, siempre que se ejecutaban, se les proporcionaban los datos deentrada y no se veía la necesidad de guardar la información en memoriasecundaria, tanto la resultante como la de entrada, para su uso posterior.

Con el tiempo, el computador adquiere un uso más comercial en lasempresas para llevar la contabilidad, la nómina y otras actividades. Estastareas, por lo general, necesitaban una serie de datos iguales para usarlosen las diferentes corridas de los programas e implicaban un gran esfuerzoporque había que entrarlos nuevamente, cada vez.

Ante este problema, aparecen los Sistemas de Archivos, donde los datos sealmacenan de manera permanente para sobrevivir a los programas que losusan; 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 mismodato aparece repetido en varios archivos. Las diferentes versiones de unmismo dato pueden estar con un grado de actualización distinto en cadalugar. Esto, además de aumentar los costos de almacenamiento y dereescritura de la información, puede dar lugar a inconsistencias: un directivopuede estar viendo un informe donde se muestra una cosa y viendo porpantalla, otra.

El segundo problema es la inflexibilidad porque cuando se quiere agruparlos datos de cierta manera no se puede hacer, debido a la organizacióndada en los archivos que no tienen ninguna clase de vínculos o presentanformatos diferentes; como en el ejemplo hipotético de la ilustración 1. Estainflexibilidad impide resolver rápidamente consultas espontáneas y aunque

Préstamo estudiantil

Ingresos y Egresos

Registro y matrícula


los datos existan, la información no puede proporcionarse relacionandodatos. Esta es la queja constante de los directivos; que teniendo lainformació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 costode efectuar cambios en las estructuras de los datos porque al cambiar larepresentación de un dato, se necesita cambiar el programa para que loreciba de la nueva manera. Además, es altamente probable que los mismosdatos se encuentren en otros archivos; entonces los cambios se propagaránde una manera incontrolable por todos los lugares, aumentando el tiempoque el personal especializado debe invertir en el mantenimiento de losprogramas y, por ende, reduciendo el tiempo que le pudieran dedicar aldesarrollo de nuevas aplicaciones.

Uno de los objetivos de los Sistemas de Bases de Datos es tener laposibilidad de usar los datos de nuevas maneras sin generar una reacciónen cadena de modificaciones difíciles sobre los otros programas existentes.El propósito, pues, del ambiente de bases de datos es separar cadaprograma 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 reorganizarlos datos. Esta característica es conocida como independencia de datos.

La tecnología de bases de datos proporciona los medios, a lasorganizaciones para que cumplan con sus objetivos de lograr máximosbeneficios (para las entidades sin ánimo de lucro, a prestar un mejorservicio) y ocupar una posición de liderazgo por las razones que seenumeran a continuación.

1. Se logra el desarrollo de aplicaciones más rápidamente porque losprogramas reutilizan los datos y procedimientos almacenados en la basede 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 lasaplicaciones, haciendo el software más tangible y de mayor valorinmediato.

3. El acceso a los datos es flexible y rápido.

4. Se pueden generar informes y formularios de pantalla sin laprogramación convencional.

5. El usuario final puede, él mismo, extraer la información que necesita ycrear nuevos tipos de datos.


En otras palabras, permite a las organizaciones implantar el justo a tiempopara tener mejor y mayor información para la toma de decisiones eincrementar su productividad.

3. DEFINICION DE UNA BASE DE DATOS

Es una colección de datos (actualmente, también de procedimientos ofunciones) almacenados de una manera permanente, que pueden sercompartidos y usados con variados propósitos por múltiples usuarios.

Un usuario determinado no tiene que ver todos los datos de la base dedatos, sólo aquellos que necesita o esté autorizado para poder cumplir consus funciones dentro de una organización.

No todos los usuarios perciben los datos de la misma manera, a pesar deque puedan ser extraídos de la misma base de datos. Por ejemplo, la fechade compra de un artículo puede ser vista por el asistente de mercadeo conun 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 integrartoda la información de una organización para evitar redundancias, esencialpara superar las limitaciones de los sistemas de archivos, a su vez, puedegenerar nuevos problemas o dificultades que se deben resolver. Entre ellos,está el problema del trabajo concurrente o simultáneo de un grupo deusuarios o aplicaciones sobre las mismas piezas de información y también elproblema 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, através, de las aplicaciones, el usuario especialista que es el que diseña yprograma las aplicaciones para los usuarios finales y, por último, la personaencargada de administrar la base de datos llamada en forma abreviada DBA(database administrator).

No obstante, cualquier persona con cargos administrativos, ingeniero oprofesional cuyo trabajo sea cambiado por los sistemas de bases de datosdeberí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 Ventajas

1. Economía de escala: esencialmente, la concentración de aplicacionesen una sola localidad puede reducir costos: menos cantidad depersonas 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 yprogramas, 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 unprofesor sea uno de los existentes en la Universidad.

7. Seguridad: se pueden especificar niveles de acceso con unagranularidad más fina, según los perfiles de los usuarios.

8. Flexibilidad y oportunidad: El uso de lenguajes de cuarta generaciónhacen más fácil la construcción de los programas por parte de losusuarios finales.

9. Mayor productividad de los programadores. Las aplicaciones nuevaspueden desarrollarse en la mitad del tiempo, o menos, que con lossistemas de archivos tradicionales debido al uso de lenguajes detercera generación.

10. Facilidades para el mantenimiento y reingeniería: se puede cambiar laestructura 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 ManagementSystem) es el software que sirve de intermediario entre el usuario y la basede datos. Tiene las siguientes funciones:


1. Interactuar en forma transparente con el manejador de archivos delsistema operativo para la actualización, almacenamiento y recuperaciónde los datos. El usuario, a excepción del DBA, no debería preocuparsepor las estructuras internas o por los procedimientos usados paramanipularlos.

2. Optimizar la búsqueda de la información.

3. Ofrecer un catálogo asequible por el usuario (autodescriptivo). Un DBMSdebe 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 sehagan todas o ninguna. Una transacción es una secuencia de pasos paracumplir una tarea, según el punto de vista del usuario final.

5. Controlar el acceso concurrente o simultáneo a los mismos datos paraque no existan conflictos por las peticiones de los usuarios oaplicaciones.

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 vistasiii) 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 datosii) Valores válidosiii) Formatos y valores por defecto


iv) Restricciones9. 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 basesde datos debe realizar muchas tareas bastante complejas y de ahí sutamaño y costo.

No obstante, en el mercado se pueden encontrar una gran variedad desistemas gestores de bases de datos con precios muy disímiles y una de lasrazones se debe a que no todos ellos cumplen con las funciones que seacaban 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 usuariosfinales, especialistas o administradores, corresponde con un nivel deabstracción.

Análisis sintáctico

Verificación deprivilegios y de laexistencia de los

objetos en la base dedatos

Diccionariode datos

Error

Optimización de laconsulta

Manejo deTransacciones

Base dedatosBitácora

Administración delalmacenamiento

C l a u d i a J i m é n e z R a m í r e z B a s e s d e D a t o s 1 0

Por lo anterior, la ANSI/SPARC ha propuesto una arquitectura considerandotres 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, estosignifica que se ocupa de la forma cómo los usuarios individualesperciben la base de datos. A diferencia de los otros dos niveles, existenmúltiples maneras de percibir la base de datos a este nivel; tantas comogrupos de usuarios finales existan en la empresa. Toda vista externa dela 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 dedatos y de las relaciones existentes entre ellos. Este nivel, es de interésprimordialmente para el usuario especialista. El esquema lógico,correspondiente con este nivel de abstracción, está conformado por ladescripció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 elque se ocupa de la forma como se almacenan los datos físicamente en lamemoria secundaria. El nivel físico de la base de datos interesa aladministrador y al usuario especialista. La descripción de este nivel deabstracción se le denomina esquema físico y está conformado por ladescripción de los datos, sus tipos, su tamaño y dominio de acuerdo conun DBMS particular.

1 2 n


Independencia de datos: es una característica de las bases de datos quepermiten modificaciones en la definición de un esquema sin afectar, en lamedida de lo posible, la reescritura del esquema inmediatamente superior.

Independencia física: cuando un cambio en el esquema físico no conducea efectuar cambios en el esquema lógico.

Independencia lógica: cuando un cambio en el esquema lógico no conllevaa un cambio en el nivel de visión. Este tipo de independencia es más difícilde 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” quetransforma los requerimientos de información en una base de datos enfuncionamiento.

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 deespacios

Construcción Implementación de la Base de Datos

El diseño conceptual parte de la especificación de requerimientos y suresultado es el esquema conceptual, cuyo propósito es describir el contenidode información de la base de datos, más que las estructuras dealmacenamiento que se necesitarán para manejar la información. Es unadescripción de alto nivel que es completamente independiente del softwarede DBMS que se use, incluso si se pensara en implementar con archivostradicionales y con algún lenguaje de programación convencional.


El diseño lógico parte del esquema conceptual y da como resultado elesquema lógico. El esquema lógico es una descripción de la estructura de labase de datos que puede procesar el software DBMS. El modelo lógico másusado actualmente, es el modelo relacional que ha sido enriquecido con losmodelos orientados por objetos. El modelo lógico no depende del DBMS enparticular, sino del modelo de datos usado por el DBMS.

El diseño físico parte del esquema lógico y da como resultado un esquemafísico. Es una descripción de cómo está almacenada la base de datos en lamemoria secundaria; describe las estructuras de almacenamiento y losmétodos usados para tener un acceso efectivo a los datos. Los esquemaslógicos y físicos se expresan haciendo uso del lenguaje de definición dedatos del DBMS elegido; la base de datos se crea y se carga, y puede serprobada. Lo mismo, puede probarse las aplicaciones sobre la base de datosy 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 acopladocon el proceso de desarrollo de aplicaciones:

Requerimientos de la organización

REQUERIMIENTOS DE INFORMACION REQUERIMIENTOS DE APLICACIONES

Estrategia Modelamiento Modelamiento

Conceptual de Chequeos Cruzados deAná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 llamadoorientado a las funciones se desarrolló en la década de 1960 consiste encentrarse en las aplicaciones y no en los datos.


El análisis funcional parte de los requerimientos de aplicaciones quedescriben las actividades y los flujos de información dentro de unaorganización para llegar a una especificación formal de los procesos yconsidera los archivos de datos depósitos de información aislados, utilizadospor cada actividad o intercambiados entre ellas; se pierde la visión de lainformación como recurso corporativo de la organización.

Los enfoques orientados a los datos y a las funciones para el diseño desistemas informáticos son complementarios, ambos proporcionancaracterísticas relevantes y se deben relacionar íntimamente como semuestra en la ilustración 2.

Lo anterior, también ha originado un el enfoque llamado orientado a objetosdonde se determinan los objetos del dominio del mundo real relevantes en lasolución del problema, con sus características y comportamiento y de estamanera juntar los dos enfoques anteriores.

Independiente del enfoque utilizado, la tarea más difícil en el proceso dedesarrollo de una base de datos es determinar los datos necesitados por losusuarios, representarlos en la base de datos y asegurar que ellos son, enverdad, usados apropiadamente. Esto se dificulta, aún más, debido a losdiferentes 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 diccionariode 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 paracada palabra.


7. MODELAMIENTO CONCEPTUAL DE DATOS

Los modelos de datos son usados para describir la realidad. Losdiseñadores usan los modelos de datos para construir esquemas que sonrepresentaciones de la realidad. La calidad de los esquemas resultantesdependerá, no sólo del modelo elegido, sino también de la habilidad delanalista.

Un modelo de datos es una serie de conceptos que se utilizan para describirun conjunto de datos y de operaciones para manipular los mismos. Cuandoun modelo de datos describe un conjunto de conceptos de una realidad sellama modelo conceptual.

El bloque de construcción común a todos los modelos conceptuales dedatos es una pequeña colección de mecanismos de abstracción:clasificación (agrupación de una clase de objetos con característicascomunes), agregación (una nueva clase formada por la reunión de variosobjetos) y la generalización o especialización (una relación de subconjuntoentre los elementos de dos o más clases).

La abstracción es un proceso mental que se aplica al seleccionar algunascaracterísticas y propiedades de un conjunto de objetos y excluir otras nopertinentes.

En el modelamiento conceptual, se identifican las propiedades estructurales(sobre los objetos, sus atributos y relaciones) y dinámicas (operacionessobre los objetos) además de ciertas restricciones de integridad, de undominio de aplicación con miras a su transformación en un modelo de másbajo nivel.

Los modelos conceptuales deben ser buenas herramientas para representarla realidad; por esta razón debe poseer, entre otras las siguientescaracterísticas:

1. Expresividad: los modelos más ricos en conceptos son más expresivos.Por ejemplo, la mayoría de los modelos conceptuales hacen usofrecuente de la abstracción de generalización lo que permite larepresentación de una gran variedad de restricciones de integridad.

2. Simplicidad: un modelo conceptual debe ser simple o fácil de entenderpor los diseñadores y por los usuarios finales. Esta propiedad y laexpresividad son objetivos en conflicto; si un modelo es semánticamenterico, es probable que no sea simple.


3. Minimalidad: esta característica se consigue si ningún concepto presentepuede expresarse por otros conceptos. Con la minimalidad se persigueque el modelo abstraiga lo esencial de la realidad, buscando laparsimonia.

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 medianterepresentaciones lingüísticas y gráficas. El éxito de un modelo de datosdepende en gran medida de su representación gráfica que debe ser lo máscompleta posible (si no requiere complementarse con una representaciónlingüística) y facilidad de lectura (si cada concepto se representa con unsímbolo gráfico claramente distinguible del resto).

El modelo Entidad-Relación es el más usado para el modelamientoconceptual 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 lossistemas de diccionarios de recursos de información (IRDS, InformationResource Dictionary Systems).

Posteriormente, el modelo fue extendido por otros autores, como RichardBarker en la metodología Case Method, para adicionar una mayorsemá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* apellidoo cargo* fecha engancheo salarioo comisión

# * número* nombre* ubicación

jefede

subordinadode

asignado a

responsablede

Los conceptos básicos de un modelo Entidad-Relación son:


• Entidad - representa una clase de objetos de la realidad, de la que senecesita mantener y conocer información.

• Relación - representa una conexión entre los objetos de una o másentidades.

• Atributo - representa una propiedad básica que caracteriza a unaentidad o a una relación.

El modelo Entidad-Relación es un medio efectivo para recopilar ydocumentar los requerimientos en un formato claro y preciso. Esto es, unmarco 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 puederefinar con facilidad. Proporciona un claro cuadro del alcance de losrequerimientos de información y sirve de base de integración de múltiplesaplicaciones, proyectos de desarrollo y paquetes comerciales.

Es importante establecer completamente los requerimientos de informaciónde la organización durante la etapa de modelamiento para evitar cambios enetapas posteriores del desarrollo, pues siempre implican costos mayoresque los que se detectan en una etapa temprana.

El modelo E-R puede ser transformado una base de datos jerárquica, enred, relacional u orientada por objetos e, incluso, a un ambiente tradicionalde desarrollo de software. Esto es, puede ser traducido a cualquier modelológico que se desee.

8. ENTIDADES

Una entidad es una clase de objetos de importancia, en el dominio delproblema, sobre la cual se debe guardar o conocer alguna propiedad.También puede definirse como una categoría. Ejemplos de entidades son:

EMPLEADOARTICULOTIQUETE

Las entidades pueden ser simples si son irreducibles o complejas cuandoestán formadas, a su vez, por otras entidades.


Cada entidad se define por los atributos y sus relaciones que poseen. Por lotanto, toda entidad debe poseer dichas propiedades. Algunos atributosposibles para la entidad EMPLEADO son: su fecha de vinculación, el salarioy cargo.

Convenciones:

ü Para dibujar las entidades en el diagrama E-R se utilizan cajas, conbordes 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 útilescuando dos grupos de usuarios usan diferentes nombres para referirse auna misma entidad.

ü Los nombres de los atributos deben ir en minúsculas.

Ejemplos:

Cada entidad suele tener múltiples ocurrencias o instancias; es decir, debetener asociada una población de objetos. Toda instancia tiene valoresespecíficos para los atributos de la entidad.

Cada instancia debe ser identificable de las otras instancias u ocurrenciasde la misma entidad. Un atributo o conjunto de atributos que identificaninequívocamente a cada instancia es llamado identificador único (IU).

Para los empleados, por ejemplo, el atributo cédula serviría comoidentificador ú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, serecomiendan 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 losrequerimientos de información. ¿Son cosas de importancia paraconsiderarlos 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 entredos entidades, o de una entidad consigo misma. Cada relación asocia unainstancia de cada una de las entidades involucradas en ella.

La sintaxis de una relación, permite una lectura:

debe una o variasCada 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 puedenespecificar 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 siguientesconvenciones:

• Una línea entre las entidades relacionadas.


• Los nombres de las relaciones se escriben en minúsculas y se colocanen 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 variasinstancias de la otra entidad

Si la relación se puede dar sólo con una y sólo unainstancia 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 DEPARTAMENTOasignadoa

responsablede

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 acontinuación.

“Cada DEPARTAMENTO puede ser responsable de uno o varios unEMPLEADOs”.

Existen tres tipos de relaciones, de acuerdo con su grado:


• De muchos a uno (n:1) que se caracteriza por tener un grado de uno omá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 PASAJEROcompradopor

poseedorde

• De muchos a muchos (n:m) que tienen un grado de uno o más en ambasdirecciones. También es una relación muy común.

Ejemplo

ARRENDADOR ALQUILERgenerador

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 quepuede que una relación de éstas entre entidades sea realmente unamisma entidad.

Ejemplo


OPERARIO encargadode

manejada por

MAQUINA

Todas las entidades, relaciones y atributos deben representar losrequerimientos 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 lasrelaciones entre un conjunto de entidades se emplea la matriz de relaciones.

Una matriz de relaciones muestra para cada entidad fila sobre el ladoizquierdo 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 partesuperior de la matriz. Si una entidad fila tiene una relación con una entidadcolumna, entonces se coloca el nombre de la relación en la celda que lasintercepta. 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 unarelación por debajo de la diagonal. Las relaciones recursivas (de una entidadconsigo misma) se representan sobre la línea diagonal.

Ejemplo

La siguiente matriz muestra las relaciones entre cuatro entidades.

CLIENTE ARTICULO ORDEN BODEGACLIENTE el generador

deARTICULO comprado

mediantealmacenado

enORDEN Hecha para Compuesta deBODEGA sitio de

almacenamiento

Una vez se tengan definidas las relaciones en la matriz, se pueden llevar almodelo entidad-relación.


ARTICULO

códigodescripción

BODEGA

identificadordirección

ORDEN

númerofecha

CLIENTE

identificador

direcciónrazó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 matrizde relaciones para examinar si existe una relación entre cada pareja deentidades.

No se deben usar los términos "relacionado con" o "asociado a" comonombres de relaciones, pues estos nombres no definen cuál tipo de relaciónse está modelando.

11. LOS ATRIBUTOS

Los atributos son información que se necesita conocer y mantener de unaentidad. Sirven para describir, identificar, cualificar, clasificar, cuantificar oexpresar 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 nodeben incluir el nombre de la entidad; ya que sería redundante como en elcaso 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 colocandentro de la caja de la entidadSe debe descomponer un atributo hasta aquella componente mínima consignificado propio. Así, el nombre de una persona debe ser descompuestoen nombre y apellidos. Los atributos que contengan fechas no se


descomponen. No obstante, el nivel de descomposición dependerá de lasnecesidades organizacionales.

Se debe verificar que cada atributo tenga un solo valor para cada instanciade la entidad; pues un atributo con múltiples valores o grupos que se repitenno son un atributo válido, en este modelo.

Para representarlos, entonces, es necesario ascenderlos a la categoría deentidad.

Ejemplo

En ESTUDIANTE, el atributo notas es multivaluado:

ESTUDIANTE

carnénombreapellido

notascarrera

Entonces, es preciso crear promover el atributo notas a la categoría de clasey establecer una relación con estudiante.

Se debe verificar que un atributo no sea calculado o derivado de los valoresexistentes de otros atributos. El atributo derivado es redundante y lasredundancias pueden conducir a inconsistencias en los valores de los datos.

Algunas veces se necesita, por cuestiones de eficiencia, tener datosredundantes; pero se debe tener muy presentes en la etapa de diseño paraque sean, en la medida de lo posible, calculados o recalculados (en el casode correcciones) automáticamente por el sistema.

Si un atributo tiene, a su vez, atributos propios; entonces debe modelarsecomo otra entidad.

Ejemplo


COMPUTADOR

referenciamarcatarjeta madrefecha de compra

COMPUTADOR

referenciamarca

TARJETA MADRE

fecha de compra

número seriechip procesadorvelocidad procesadorchip coprocesador

para

poseedora de

Existen atributos obligatorios y otros que pueden ser opcionales. El atributoobligatorio significa que en todo momento es importante conocer el valor quetoma 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* nombreo profesión* sexoo peso

12. IDENTIFICADORES UNICOS

Un identificador único (IU) puede ser cualquier combinación de atributos y/orelaciones que sirven para identificar inequívocamente una ocurrencia deuna 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 asignaun 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úmeromás el número de la sucursal.


Observe cómo, en este caso, se coloca una barra para indicar que larelación forma parte del identificador único.

Una relación parte de un Identificador Unico debe ser obligatoria y de gradouno 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é delestudiante, el código del curso y de la fecha de inscripción

INSCRIPCION

ESTUDIANTE CURSO

# * carné* nombre * nombre

# * código

# * fecha

de

registradoen

para

motivopara

o nota definitiva

Una entidad puede tener más de un identificador único. Este es el caso deun estudiante que posee un carné y un documento de identificación (cédulao 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, nose 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.

Ejemplo


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 ladescripción del artículo, de la unidad de medida y de la marca. Para evitarun identificador único tan largo, es mejor crear un código artificial que seráúnico para cada instancia.


NORMALIZACION DEL MODELO DE DATOS


13. La normalización

La normalización es un concepto de bases de datos relacionales, pero susprincipios 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 debenposeer un sólo valor (ser atómicos).

La segunda forma normal enuncia que todo atributo debe ser dependientedel 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 unsólo valor.

Revise que ningún atributo tenga más de un valor para cada instancia deuna 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, laentidad PACIENTE, no está en primera forma normal debemos crear unanueva entidad CITA MEDICA con una relación uno a muchas conPACIENTE.


CITA MEDICA

en

paraPACIENTE

# * número# * identificación

* nombre* dirección* teléfono

* fecha figura

SOLUCION: Si un atributo tiene múltiples valores, cree una entidadadicional y relaciónela con la original con una relación n:1.

Regla de la segunda forma normal: todo atributo debe ser dependientedel identificador único de la entidad a la que pertenece.

Para validar si entidad cumple con la segunda forma normal, verifique quecada identificador único específico determine una sola ocurrencia para cadaatributo. Asegúrese de un atributo no dependa únicamente de una parte delIU 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íficopara nombre, dirección y teléfono. Entonces los atributos están bienubicados.

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

por


En el ejemplo anterior, cada instancia de BANCO y de un número de cuentadeterminan una fecha específica de apertura. El atributo localización estámal ubicado. Depende del BANCO pero no del número de la cuenta. Nodeberí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 esIU

# * 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 entidadEDITORIAL y se reubican los atributos.

# número # codigo

REVISTA

* nombre * fecha publicación

EDITORIALeditada

por

editora

de

Solución: si un atributo no IU depende de otro que tampoco es IU, muevaambos 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ónde muchos a muchos se resuelve adicionando una entidad de intersección.

Ejemplo


Considere una relación muchos a muchos entre COMPAÑÍA DE SEGUROSy SINIESTRO.

El valor del seguro y la fecha de vencimiento del mismo, son atributos de larelación entre SINIESTRO y COMPAÑÍA DE SEGUROS. Los atributos sólodescriben a las entidades.

Si los atributos describen una relación, entonces ésta debe ser resuelta. Seresuelve una relación n:m con una entidad nueva de intersección y dosrelaciones 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 vencimientopertenecen a la entidad POLIZA.

Para resolver una relación muchos a muchos, se ubica la entidad deintersección de tal manera que las patas de gallina siempre se dirijan haciala 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 deintersecció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 atributosadicionales que la describan. Puede ocurrir, sin embargo, que obtengamosuna entidad de intersección sin atributos; en este caso tendremos sólo unareferencia cruzada entre las ocurrencias de las entidades y el identificadorúnico para la entidad de intersección, estará siempre compuesto de lasrelaciones de las dos entidades de las cuales se originó.


Una entidad de intersección sin atributos es la excepción a la regla de queuna entidad siempre debe poseer atributos para poder ser, realmente, unaentidad.

Ejemplo

ACTOR PELICULA# código

* nombre artistico

o nombre real

o fecha nacimiento

* nombre* clasificación

protagonista

protagonizada

# identificadorde

por

Para esta relación de muchos a muchos, no se identifican atributosasociados. Entonces, se resuelve con una entidad de intersección sinatributos.

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 unarelación de jerarquía se pueden propagar a través de múltiplesrelaciones 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 dondese 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 UNIDADdonde se localiza.

Cuando las estructuras jerárquicas cambian a menudo, es mejor crearatributos artificiales para ayudar a identificar las entidades.

15. Relaciones recursivas

Una relación recursiva es aquella que posee una entidad consigo misma.


Ejemplo

EMPLEADO

# cédula* nombreo profesión* cargo* fecha ingreso* salario

a cargo

de

bajo ordenes

de

La convención para dibujar una relación recursiva es conocida con elnombre de “cola de marrano”. Puede aparecer en cualquier lado de la cajade la entidad; pero recordando que el lado de muchos siempre va hacia laizquierda 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ódigoo nombreo dirección

LOCALIZACION

dentro de

conformada

por

o propietario


La entidad recursiva debe incluir todos los atributos de cada entidadindividual. La relación recursiva debe ser siempre opcional en ambasdirecciones; 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 cuandoIBM y Rockwell International desarrollaron las primeras versiones de unsistema conocido como DL/I con el propósito de administrar la gran cantidadde datos del proyecto espacial APOLO [GON96]. Posteriormente, leadicionan 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 clasificarpor el método empleado para estructurar los datos internamente. A lasestructuras de datos utilizadas se les llaman también modelos físicos dedatos.

El IMS es un DBMS de tipo jerárquico, es decir, se sustenta sobre unaestructura de datos jerárquica o de árbol; en donde los nodos representanlas 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 decomunicación

Aplicación 1 Aplicación n



Descripciones de la base de datos


Las descripciones de la base de datos, definen una base de datos física queagrupa la información sobre todos los segmentos (que representan lasentidades) con su longitud y clave, entre otras cosas.

El programa de comunicación define el mecanismo usado para el paso delmodelo lógico al físico.

Finalmente, cada aplicación define el conjunto de procedimientos y defunciones que requiere un usuario final.

Los desarrolladores de bases de datos jerárquicas se referían a lasrelaciones 1:n, como relaciones “padre-hijo” entre los registros; que sepodían implementar por medio de adyacencia física (registro padre + arreglode registros hijos) o por medio de punteros. Las bases de datos jerárquicasse 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 registrohijo no podía tener dos registros padres distintos. Esta situación impedíarepresentar 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

Cédula Nombre Cédula Nombre


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 deestudiantes matriculados en un curso dado, se tendría que usar la segundarelación. El modelo jerárquico obliga a repetir información para darrespuesta 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 datosjerárquicas, con las relaciones de muchos a muchos, surgen las bases dedatos en red. La estructura de un DBMS en red es esencialmente la mismaque en el modelo de datos jerárquico; excepto que un “miembro” (registrohijo) 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 implementadasmediante 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ó otrorelacionado con el manejo de punteros; pues además de aumentar lacomplejidad, las relaciones que se creaban por medio de ellos hacían que

ESTUDIANTE CURSO

REGISTRO

123 | Juan Pérez

registro 128 registro 145

registro 146 registro 149


se tuviera definir de antemano cómo se consultarían los datos; restandoflexibilidad 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 lateoría de conjuntos y en la lógica de predicados de primer orden. La idea de Coddconsistía en evitar el uso de punteros por parte de los usuarios especialistas parafacilitar la gestión de los datos y sus relaciones; el DBMS se debería encargar delmanejo de los punteros de las estructuras de datos físicas. La técnica consistía enrepresentar los datos como tablas bidimensionales; una manera mucho mássencilla y comprensible y por ello, este modelo de datos logró la popularidad quehoy sigue teniendo.

Codd encontraba otro problema básico de los modelos primitivos, además delmanejo de punteros, que era la restricción de procesar sólo un registro a la vez ypor ello el usuario debía controlar condiciones como "fin de archivo". En lugar deello, él quería que se pudiera realizar operaciones sobre conjuntos de datos y queel DBMS controlara los detalles o las condiciones para llevar a cabo estasoperaciones.

Ventajas del modelo relacional

1. Separación clara del nivel lógico y el físico. El usuario no ve para nada el nivelfísico.

2. Simple y fácil de trabajar con él. La representación de los datos por tablas esintuitiva 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 formaexplícita; aunque en algunos manejadores de bases de datos se puede teneracceso a los objetos mediante su ROWID.

Terminología

Antes de explorar el modelo relacional es importante dar la definición de losconceptos básicos que éste incluye.

Relaciones y Tablas

La estructura básica del modelo relacional, y de ahí su nombre, es la relación. Elté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 unconcepto abstracto de un estructura bidimensional. Una relación se puede definirpor comprensión o por extensión. Así, por ejemplo, podemos definir porcomprensión la relación R:

R = { x / x(identificación, nombre, telefono) es estudiante de la UniversidadNacional }

La estructura bidimensional que asociamos familiarmente a una relación es latabla, 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 valoresen los atributos.

Tuplas, Atributos y Cardinalidad

Cada instancia o fila de una relación se le denomina tupla y a cada columna se ledenomina también atributo. Al número de atributos se le denomina el grado deuna relación y al número de tuplas se le denomina cardinalidad o extensión de larelación.

Dominio

Un dominio es un conjunto aceptable de valores para un atributo. Un dominiopuede ser compartido por varios atributos y se puede restringir para velar por laintegridad de la base de datos.

Clave Primaria

Las claves sirven para la identificación de las tuplas. Se utiliza, entonces, unacolección mínima de atributos como clave primaria para representar losidentificadores únicos del modelo E-R.

Clave candidata:


Atributo (columna) o atributos que identifican a una tupla (fila) dada. La claveprimaria es la clave candidata elegida por el DBA.

Clave foránea:

Es un atributo que es clave primaria en otra relación. Permite explícitamenteespecificar las relaciones entre dos diferentes tablas y es también un mecanismopara 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 yse hace al tiempo con el diseño de la aplicación de las aplicaciones que sepiensen desarrollar, en paralelo.

El diseño, produce especificaciones para la implementación de bases de datosrelacionales; incluyendo definiciones para las relaciones, los índices, las vistasque se deben crear y otras especificaciones sobre el espacio de almacenamiento.Se debe documentar el sistema, con una tabla de especificaciones para cadarelación en el modelo relacional.

Tabla de Especificación de la Relación EMPLEADOSNombre

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 CFpara una columna de clave foránea.


• Se usan sufijos para distinguir entre múltiples columnas de CF en una tablasimple, por ejemplo, CF1 y CF2. Se rotulan múltiples columnas clave con elmismo sufijo.

• Se usa el rótulo NN para las columnas que deben ser definidas como nonulas (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 lafigura número 1, se empleará para ilustrar como transformar el modelo E-R en unmodelo 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 derelaciones, 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

* Nombreo Cuotao Duración

ESTUDIANTE# Identificación* Nombre* Apellido* Teléfono

PROFESOR# Identificación* Nombre* ApellidooTeléfono oficina


Las entidades simples, entidades que no son subtipos o supertipos, ni participanen una relación exclusiva en el modelo E-R, se transforman en relaciones delmodelo relacional.

Se crea una tabla de especificación para cada entidad simple. Inicialmente secomienza 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. Seacostumbra a utilizar el plural del nombre de la entidad para el nombre de larelació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 debeespecificar que los atributos requeridos son columnas NOT NULL (NN).

Ejemplo: Como los atributos identificación, nombre y apellido son atributos deentrada obligatoria de la entidad PROFESOR, se transforman en columnas nonulas. Se debe, entonces, designar sus columnas como NOT NULL.

PROFESORNombre

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 perosignificativo. El nombre de la columna debe ser fácil de recordar. Es bueno utilizarabreviaturas consistentes para evitar confusión al programador y al usuario. Porejemplo, Número será abreviado como NO o NUM. Esto es, NODEPTO oNUMDEPTO?

Los nombres de las columnas cortos reducen el tiempo requerido para laejecución de comandos del SQL. Para determinar los tipos de datos adecuadoses ú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 CLAVESPRIMARIAS

En este paso, cada atributo que hace parte de los identificadores únicos de laentidad 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ñadirlas columnas de las claves foráneas a la tabla y marcarlas como parte de la claveprimaria.

Ejemplo: el identificador único de la entidad INSCRIPCION está compuesto porlas relaciones con las entidades CURSO y ESTUDIANTE. Por lo tanto, esnecesario añadir dos columnas claves foráneas, a la tabla INSCRIPCION, paraformar su clave primaria.

Tabla: INSCRIPCION

Columna FCH_INS FCH_FIN NOTA COD_CUR ID_ESTTipo Clave CP, CF1 CP, CF2

Nulos/Unicos

NN NN, U1 NN, U1

Ejemplos 20/08/98 29/09/98 --- 344 4759305/06/98 --- --- 401 1540214/06/98 28/06/98 4.1 717 5139408/05/98 28/06/98 4.2 717 9457205/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 entreellas, por ejemplo, CF1 y CF2. Debemos rotular varias columnas claves con elmismo sufijo

• Una CP compuesta debe ser única en combinación y se debe rotular comoU1.

PASO 4 - CONVERTIR LAS RELACIONES EN CLAVES FORANEAS


Para una relación 1:n, se debe tomar el IU de la entidad con cardinalidad de uno yponerla en la tabla relacional que corresponde a la entidad con cardinalidad demuchos.

Por ejemplo, se toma la clave primaria Identificación en el lado de uno, y se colocaen la relación CURSO que está en el lado de "muchos".

instructor de dictado por

Tabla: CURSONombreColumna

COD_CUR NOMBRE CUOTA DUR ID_PROF

Tipo deClave

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 DEUN DBA

900 3 73

• Se debe seleccionar un nombre único para la columna CF y rotularla comoCF.

• Para relaciones obligatorias también se debe especificar que la columna esno nula, NN.

Para una relación 1:1 obligatoria, se debe colocar la clave foránea única en latabla al lado de la obligatoriedad y usar la restricción de NOT NULL para hacercumplir la relación de obligación.

Ejemplo: la relación entre COMPUTADOR PERSONAL y TARJETA MADRE ESUNA RELACIÓN 1:1 y es obligatoria hacia tarjeta madre. Entonces, se coloca laclave 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* ApellidooTeléfono oficina


como NOT NULL. ID_TM es la clavbe foránea añadida. Esta columna tambiénse 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 permitirvalores nulos, en algunos casos.

Si una relación 1:1 es opcional en ambas direcciones, se puede colocar la claveforánea en la tabla que corresponda a cualquier entidad participante en larelación.

Cuando exista una relación recursiva 1:n, se debe adicionar una columna CF a latabla 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 tablaEMPLEADO por cada Jefe de empleado. Nombrar la columna ID_JEFE parareflejar la relación.

jefe de

bajo órdenes de

Tabla: EMPLEADO

NombreColumna

ID_EMP NOMBRE APELL ID_JEFEEMPLEADO

#*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. Lacolumna CF se nombra de tal manera que refleje la relación.

Debe observarse, además, que una CF recursiva nunca será NOT NULL porquese crearía un ciclo infinito.

Para una relación recursiva 1:1, es necesario añadir una clave foránea única a latabla. 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

NombreColumna

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 paraasegurar la relación 1:1. Se garantiza que la combinación sea únicarotulá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. Seescoge 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ónincluida en el arco.

Así, por el ejemplo, el modelo E-R de la figura número 2, el arco se extiende sobreel final de tres relaciones de "muchos". Entonces, se deben adicionar tres clavesforáneas a la relación de OFICINAS:

OFICINASNombreColumna

ID_EDIF NO_OFIC ID_IND COD_SOC NO_COMP

Tipo de Clave CP CP CF1 CF2 CF3

Valoresnulos/únicos

NN, U1 NN, U1

El diseño de Arco Explícito soporta múltiples claves foráneas con diferentesformatos. Por ejemplo, ID_IND, COD_SOC y NO_COMP pueden tener diferentesformatos de columna.

Sin embargo, con este tipo de diseño, la aplicación debe hacer cumplir laexclusividad 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áneasimple y una columna adicional utilizada para indicar cuál de las tablas esreferenciada por la columna clave foránea en cada fila. Como las relaciones sonexclusivas, 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 declave foránea simple y añadir una columna de tipos para indicar cuál de las trestablas es la referenciada en cada fila. Por ejemplo, I por INDIVIDUO, S porSOCIEDAD y C por COMPAÑIA.

OFICINASNombreColumna

ID_EDIF NO_OFIC ID_RENTADOR TIPO_RENTADOR

Tipo de Clave CP CP CF

Valoresnulos/ú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 columnasañadidas como NOT NULL.

Con este tipo de diseño, las claves foráneas deben compartir el mismo formato entodas las tablas de referencia y la relación de exclusividad queda aseguradaautomáticamente.

PASO 6- ESCOGER OPCIONES PARA LAS RELACIONESSUPERTIPO/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 lossubtipos. Es decir, la tabla resultante contendrá las instancias de todos lossubtipos.

Este diseño es apropiado cuando los subtipos tienen pocos atributos y relacionespropias 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 figura3, en una sola tabla.

EMPLEADO

NombreColumna

NUM NOMB APELL TIPO SALARIO VLR_HORA

VLR_EXTRA

NUM_EMP

COD_DEP

Tipo deClave

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 consultarfrecuentemente el supertipo, esta opción es apropiada.

• Se puede tener acceso a los subtipos mediante vistas.

Desventajas de este diseño


• Los requerimientos de atributos no nulos, en cada subtipo, no se puedenhacer cumplir desde la definición de la base de datos.

• La lógica de la aplicación debe proveer distintos atributos, dependiendo deltipo.

Opción 2 - Diseño de los subtipos en tablas diferentes

Esta opción consiste en convertir los subtipos en tablas diferentes -una para cadasubtipo. Cada tabla contendrá instancias solamente de ese subtipo.

Pasos de diseño

• Crear una tabla para cada subtipo• En cada tabla de un subtipo, crear las columnas para cada atributo del

subtipo.• En cada tabla de un subtipo, crear las columnas para los atributos del

supertipo.• En cada tabla de un subtipo, crear columnas CF para cada relación del

subtipo.• En cada tablas del subtipo, crear columnas CF para cada relación del

supertipo.

Empleando este método de diseño, la relación supertipo/subtipo de la figura 3,conduce a convertir el supertipo EMPLEADO en dos tablas -una por cada subtipocomo se muestra a continuación.

Tabla: EMPLEADO DE PLANTA

Nombre

Columna

NUM_ESC NOMB APELL SALARIO COD_DEP

Tipo Clave CP CF

Nulls/Unique NN, U NN NN NN NN

Ejemplos 4579 Jaime Pérez 29000 40

6631 Ana Casas 25000 351190 Juan Hoyos 42700 40370 Pedro Díaz 44050 30

A B

C

TABLAB

TABLAC


800 Luis Ruiz 38450 35

Tabla: EMPLEADO TEMPORAL

Nombre

Columna

NUMERO NOMB APELL VLR_HORA VLR_EXTRA NUM_EMP COD_DEP

Tipo Clave CP CF1 CF2

Nulls/

Unique

NN, U NN NN NN NN NN NN

Ejemplos 7147 Alex Ríos 8.50 12.75 201 35

6794 Lili Vega 6.75 11.50 150 30

941 Saúl Mejía 12.00 18.00 201 45

Se usa el diseño de subtipos en tablas diferentes cuando los subtipos tienenmuchos atributos y relaciones específicas o particulares.

Ventajas de este diseño

• La opcionalidad de los atributos del subtipo se hace cumplir desde ladefinición de la base de datos.

• La lógica de la aplicación no requiere comprobaciones para los subtipos

Desventajas de este diseño

• El acceso al supertipo requiere del operador UNION o una vista creada coneste operador.

• Las vistas que unen las dos tablas son solamente de lectura.

• El mantenimiento de identificadores únicos a través de los subtipos es másdifícil de implementar, cuando los subtipos son excluyentes.

tabla de contenido 1. breve historia de las ......tabla de contenido 1. breve historia de las bases...

Documents