Diseño de Bases de Datos.pptx

I N G . S A N D RA E S C O T O

DISEÑO DE BASES DE DATOS

DISEÑO DE BASES DE DATOS

• Objetivo:• Conocer que es una base de datos• Diferenciar entre datos e información• Distinguir sus componentes• Saber aplicar la integridad y seguridad• Conocer los tipos de bases de datos• Diferenciar entre los modelos de bases de datos

¿QUÉ ES UNA BASE DE DATOS?

• La base de datos se puede definir de manera sencilla como un conjunto de datos organizados y relacionados entre sí, en relación con algún propósito o tema en concreto.

• En la actualidad las bases de datos tienen como objetivo manejar grandes volúmenes de datos a los cuales se pueda acceder automáticamente en una forma rápida y simple, independientemente de los programas que los controlan; es decir, que aunque la base de datos esté creada con Microsoft Access, por ejemplo, ésta pueda ser controlada o administrada por Visual Basic, SQL, etcétera.

COMPONENTES DE UNA BASE DE DATOS

• Hardware: constituido por dispositivo de almacenamiento como discos, tambores, cintas, usb, etc.• Software: que es el DBMS o

Sistema Administrador de Base de Datos.• Datos: los cuales están almacenados de acuerdo

a la estructura externa y van a ser procesados para convertirse en información.

APLICACIONES GENERALES DE UNA BASE DE DATOS

• Las bases de datos son ampliamente usadas en diferentes ámbitos como pueden ser:• Bancos: Para información de los clientes, cuentas

y préstamos, y transacciones bancarias• Líneas aéreas: Para reservaciones en información

de planificación.• Universidades: Para información de los

estudiantes, matrículas de las asignaturas y cursos.


• Transacciones de tarjetas de crédito: Para compras con tarjetas y generación mensual de estados de cuenta.• Telecomunicaciones: Para guardar un registro de

las llamadas realizadas, generación mensual de facturas, almacenar información de las redes de comunicación.• Finanzas: Para almacenar información sobre

grandes empresas, ventas y compras de documentos formales financieros, como bolsa y bonos.


• Ventas: Para información de clientes, productos y compras.• Producción: Para la gestión de la cadena de

producción y para el seguimiento de la producción de elementos en las factorías, inventarios de elementos en almacenes y pedidos de elementos.• Recursos humanos: Para información sobre los

empleados, salarios, impuestos y beneficios, y para la generación de las nóminas.

IMPORTANCIA DE LAS BD

• La importancia de los sistemas de bases de datos se puede notar en la actualidad ya que los vendedores como Oracle están entre las mayores compañías de software en el mundo y los sistemas de bases de datos forman una parte importante de la línea de productos de compañías más diversificadas como Microsoft e IBM.

TIPOS DE USUARIOS EN BASE DE DATOS

• Usuario Final: es la persona que utiliza los datos, esta persona ve datos convertidos en información:• Desarrollador de Aplicaciones: es la persona que

desarrolla los sistemas que interactúan con la Base de Datos.• DBA: es la persona que asegura integridad,

consistencia, redundancia, seguridad este es el Administrador de Base de Datos quien se encarga de realizar el mantenimiento diario o periódico de los datos.

• Las personas tienen acceso DBMS se clasifican de la siguiente manera:• USUARIOS INGENUOS. – Son aquellos que

interactúan con el sistema por medio de aplicaciones permanentes.• USUARIOS SOFISTICADOS.- son aquellos con la

capacidad de acceder a la información por medios de lenguajes de consulta.

• PROGRAMADORES DE APLICACIÓN.- son aquellos con un amplio dominio del DML capaces de generar nuevos módulos o utilerías capaces de manejar nuevos datos en el sistema.• USUARIOS ESPECIALIZADOS.- son aquellos que

desarrollan módulos que no se refieren precisamente al manejo de los datos, si no a aplicaciones avanzadas como sistemas expertos, reconocimientos de imágenes, procesamiento de audio y demás.

DIFERENCIA ENTRE DATOS E INFORMACIÓN

Aunque en ocasiones suelen confundirse o usarse de manera equivocada, para los propósitos de este libro es fundamental distinguir entre los conceptos de datos e información.• Datos: Son hechos aislados que pueden registrarse

mediante números, letras o símbolos en bruto, y de los que podría decirse que constituyen la materia prima de la información.

• Información: Son los datos registrados pero ahora organizados o procesados de determinada manera que llegan a tener algún sentido; esto es, se puede decir que son datos relacionados en un contexto de significación más amplio.

DIFERENCIA ENTRE BD DE ARCHIVOS SIMPLES Y BD RELACIONALES

• Base de datos de archivos simples.• Son bases de datos elementales para

determinadas situaciones de usuario único o de pequeños grupos cuyo objetivo sea mantener listas sencillas como inventarios, agendas, directorios, en donde los datos se almacenan en un solo archivo (tabla); ejemplo de estas bases de datos son los trabajos realizados en una hoja de cálculo, a las que también se les conoce como bases de datos planas.

• Base de datos relacionales.• Formada por un conjunto de tablas relacionadas

por un campo en común, puede también ser definida como un conjunto de relaciones. Este tipo de base de datos son las más frecuentes en las empresas comerciales de hoy en día.• Base de datos: se conforma por un conjunto de

tablas o archivos relacionados entre sí.• Relación: es el vínculo entre dos o más entidades

que describe alguna interacción entre ellas y que da origen a las tablas.

• Tabla: es un arreglo bidimensional organizado por filas y columnas se conforma por un conjunto de registros).• Registro: es una fila de una tabla (se conforma

por un conjunto de campos).• Campo: es la unidad de datos más pequeña, que

representa cada elemento de dato (se conforma por un conjunto de caracteres).

NIVELES DE ABSTRACCIÓN EN BASE DE DATOS


• Externo: esa es la visión del usuario final, se ve cómo se maneja los datos ya convertidos en información.• Es aquel en el que se presenta al usuario final y

que puede combinaciones o relaciones entre los datos que conforman a la base de datos global. Puede definirse como la forma en el que el usuario aprecia la información y sus relaciones.


• Conceptual: se ve como está estructurado la Base Datos, equipos de campo tiene como están estructurado los registros.• Es aquel en el que se definen

las estructuras lógicas de almacenamiento y las relaciones que se darán entre ellas. Ejemplos comunes de este nivel son el diseño de los registros y las ligas que permitirán la conexión entre registros de un mismo archivo, de archivos distintos incluso, de ligas hacia archivos.


• Interno: se ve como se almacena los datos físicamente.• Es aquel en el que se determinan las

características de almacenamiento en el medio secundario. Los diseñadores de este nivel poseen un amplio dominio de cuestiones técnicas y de manejo de hardware. Muchas veces se opta por mantener el nivel físico proporcionado por el sistema operativo para facilitar y agilizar el desarrollo

INTEGRIDAD DE DATOS

• Conjunto de seguridades que son utilizadas para mantener los datos correctos.• Ocurre cuando no existe a través de todo el

sistema procedimientos uniformes de validación para los datos.• Fuente de Error: estas fuentes de error se

originan si el programa de entrada de datos no está validado. Ej: fallas de hardware, actualizaciones incompletas, defectos del software, inserción de datos no válidos, errores humanos.

SEGURIDAD DE LOS DATOS

• La seguridad de los datos se puede definir en las siguientes aspectos:• Objeto a asegurar: el primer objeto a asegurar

son los objetos, programas y finalmente al esquema.• Codificación de Claves: el DBMS provee la

seguridad de los Login (usuario y password).• Control de Acceso: se especifican seguridades

contra accesos indicados orientado a personas no autorizada.

VENTAJAS DE LAS BD

• Las bases de datos, presentan una multitud de ventajas frente a los sistemas clásicos de archivos o bases de datos planas, que surgen como respuesta al nuevo planteamiento de los sistemas orientados hacia los datos, con la finalidad de mejorar la calidad de las prestaciones de los sistemas informáticos y aumentar su rendimiento.

• Las bases de datos son un instrumento, que supone un distinto enfoque en la gestión de datos, y su éxito o su fracaso estará condicionado por el uso que de ellas sepamos hacer, no sólo los técnicos, sino también los directivos

A) INDEPENDENCIA DE LOS DATOS RESPECTO A LOS TRATAMIENTOS Y VICEVERSA

• La mutua independencia de datos y tratamientos lleva a que un cambio de estos últimos no imponga un nuevo diseño de la base de datos. Por otra parte, la inclusión de nuevas informaciones, desaparición de otras, cambios en la estructura física o en los caminos de acceso, etc., no deben obligar a alterar los programas. • La flexibilidad que proporciona la independencia

de los datos y programas es muy importante para conseguir sin excesivos costos la continua adaptación del sistema de información a la evolución de las organizaciones.

B) COHERENCIA DE LOS RESULTADOS

• Debido a que la información de la base de datos se recoge y almacena una sola vez, en los tratamientos se utilizan los mismos datos, por lo que los resultados de todos ellos son coherentes y perfectamente comparables. Además, al no existir (o al menos disminuir en gran medida) la redundancia en los datos, desaparece el problema que se presentaba en el enfoque clásico de que el cambio de un dato obligaba a actualizar una serie de archivos.

C) MEJOR DISPONIBILIDAD DE LOS DATOS PARA EL CONJUNTO DE LOS USUARIOS

• Cuando se aplica la metodología de bases de datos, cada usuario ya no es propietario de los datos, puesto que éstos se comparten entre el conjunto de aplicaciones, existiendo una mejor disponibilidad de los datos para todos los que tienen necesidad de ellos, siempre que estén autorizados para su acceso.

D) MAYOR VALOR INFORMATIVO

• Puesto que la base de datos ha de ser reflejo del mundo real, en ella se recogen las interrelaciones entre los datos, por lo que el valor informativo del conjunto es superior a la suma del valor informativo de los elementos individuales que lo constituyen; es decir, actúa el efecto de sinergia.

E) MEJOR Y MÁS NORMALIZADA DOCUMENTACIÓN DE LA INFORMACIÓN, LA CUAL ESTÁ INTEGRADA CON

LOS DATOS

• En el enfoque clásico los datos se encuentran separados de su contenido semántico; los primeros se almacenan en archivos y su descripción se hace mediante un lenguaje de programación que se encuentra en los programas. La documentación de los datos, realizada por el analista o programador, es en general insuficiente, y a veces incluso inexistente. Además, por lo común, la estandarización brilla por su ausencia. Este problema se acentúa en gran medida en la base de datos, ya que en la misma base se incluyen no sólo los datos, sino también la semántica de los mismos.

F) MAYOR EFICIENCIA EN LA RECOGIDA, VALIDACIÓN E INTRODUCCIÓN DE LOS DATOS EN EL

SISTEMA

• Al no existir apenas redundancias, los datos se recogen y validan una sola vez, aumentando así el rendimiento de todo el proceso previo al almacenamiento.

G) REDUCCIÓN DEL ESPACIO DE ALMACENAMIENTO

• La desaparición (o disminución) de las redundancias, así como la aplicación de técnicas de compactación, lleva en los sistemas de bases de datos a una menor ocupación de almacenamiento secundario

DESVENTAJAS DE LAS BASES DE DATOS

• Sin embargo también existen algunas desventajas al momento de utilizar bases de datos como son:

A) INSTALACIÓN COSTOSA

• La implantación de un sistema de bases de datos puede llevar consigo un costo elevado, tanto en equipo físico (nuevas instalaciones o ampliaciones), como en el lógico (sistemas operativos, programas, compiladores, etc., necesarios para su uso), además del mismo costo de adquisición y mantenimientos del SGBD.

B) PERSONAL ESPECIALIZADO

• Los conocimientos, que resultan imprescindibles para una utilización correcta y eficaz y sobre todo para el diseño y administración de las bases de datos, implican una necesidad de personal especializado.

C) IMPLANTACIÓN LARGA Y DIFÍCIL

• Debido a las causas apuntadas anteriormente, la implantación de una base de datos puede convertirse en una tarea larga y laboriosa. Las dificultades que van apareciendo a lo largo de su desarrollo llevan en general a que se superen ampliamente los plazos inicialmente previstos.

D) FALTA DE RENTABILIDAD A CORTO PLAZO

• La implantación de un sistema de base de datos, tanto por su costo en personal y en equipos como por el tiempo que tarda en estar operativo, no resulta rentable a corto plazo, sino a medio o, incluso, a largo plazo.

E) ESCASA ESTANDARIZACIÓN

• Un problema muy importante que se pone de manifiesto en el momento de la creación de una base de datos, es la falta de estandarización que facilite a los usuarios en el manejo de los sistemas de bases de datos. Empieza, sin embargo, a observarse ya una preocupación por este tema, y van apareciendo estándares

F) DESFASE ENTRE TEORÍA Y PRÁCTICA

• Al existir un considerable avance de la teoría en relación con la práctica, en muchas ocasiones los usuarios, especialmente los directivos, se engañan respecto a las prestaciones reales que pueden proporcionarles los SGBD actuales, creyendo que constituyen ya una realidad ciertos aspectos que todavía son sólo teóricos.

TIPOS DE BASES DE DATOS (ESTRUCTURAS)

• Los sistemas de gestión de bases de datos o de administración de bases de datos (SGBD o DBMS) organizan y estructuran los datos de tal modo que puedan ser accesados, almacenados, procesados y recuperados por múltiples usuarios y programas de aplicación, para crear determinada información. A continuación se exponen las distintas estructuras en que se organizan las bases de datos.

MODELO JERÁRQUICO

• Fue la primera estructura en utilizarse, a finales de los años sesentas de: siglo XX, y se enfocaba sobre todo en el establecimiento de jerarquías o niveles entre los distintos campos de la base de datos, basándose en el criterio de que los campos de mayor jerarquía son los más genéricos.

MODELO JERÁRQUICO

• De ahí que su estructura sea arborescente y que para acceder a un campo que se encuentre en cualquier nivel, es necesario localizarlo partiendo del nivel superior; es decir, se maneja una organización de Padre-Hijo.

MODELO DE RED

• Es una estructura donde existe más de una conexión o enlace entre los campos de la base de datos, de tal manera que se pueda acceder a los datos desde diferentes localidades, gracias a la interconexión de los datos entre los distintos niveles, sin la necesidad de iniciar con los campos de mayor jerarquía.

MODELO DE RED

• Este modelo nace para resolver la lentitud de la organización jerárquica, permitiendo múltiples relaciones Padre-Hijo.

MODELO RELACIONAL

• Este tipo de bases de datos se caracteriza porque su estructura no se basa en campos, sino en las tablas en su conjunto; es decir, la información se organiza por categoría de datos, en las cuales hay campos en común entre ellas y forman lo que se conoce como relaciones.

MODELO RELACIONAL

MODELO ORIENTADO A OBJETOS

• Estas bases de datos agrupan los elementos de datos y sus características, ya que define sus atributos y procedimientos asociados en elementos complejos llamados objetos, en donde un objeto puede ser cualquier cosa, un color, una casa, un producto, etcétera, y se diseñan con el objetivo de trabajar en conjunción con lenguajes de programación orientados a objetos como Java, C#, Visual Basic.NET, C++, etcétera, ya que usan el mismo modelo de datos.

MODELO ENTIDAD – RELACIÓN

• En este modelo todos los datos son almacenados en relaciones, y como cada relación es un conjunto de datos, el orden en el que estos se almacenen no tiene mayor relevancia (a diferencia de otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja de que es más fácil de entender y de utilizar por un usuario no experto. La información puede ser recuperada o almacenada por medio de consultas que ofrecen una amplia flexibilidad y poder para administrar la información.

• Este modelo considera la base de datos como una colección de relaciones. De manera simple, una relación representa una tabla que no es más que un conjunto de filas, cada fila es un conjunto de campos y cada campo representa un valor que interpretado describe el mundo real. Cada fila también se puede denominar tupla o registro y a cada columna también se le puede llamar campo o atributo.

ESQUEMA

• Un esquema es la definición de una estructura (generalmente relaciones o tablas de una base de datos), es decir, determina la identidad de la relación y que tipo de información podrá ser almacenada dentro de ella; en otras palabras, el esquema son los metadatos de la relación.

ESQUEMA

• Todo esquema constará de:• Nombre de la relación (su identificador). • Nombre de los atributos (o campos) de la relación

y sus dominios; el dominio de un atributo o campo define los valores permitidos para el mismo, es equivalente al tipo de dato por ejemplo character, integer, date, string, etc.

INSTANCIAS

• Una instancia de manera formal es la aplicación de un esquema a un conjunto finito de datos. En palabras no tan técnicas, se puede definir como el contenido de una tabla en un momento dado, pero también es valido referirnos a una instancia cuando trabajamos o mostramos únicamente un subconjunto de la información contenida en una relación o tabla.

RESTRICCIONES

• Son reglas que deben mantener los datos almacenados en la base de datos.

CORRESPONDENCIA DE CARDINALIDADES

• Dado un conjunto de relaciones en el que participan dos o más conjuntos de entidades, la correspondencia de cardinalidad indica el número de entidades con las que puede estar relacionada una entidad dada.

CORRESPONDENCIA DE CARDINALIDADES

• Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, la correspondencia de cardinalidades puede ser:• Uno a uno (1:1): Una entidad de A se relaciona

únicamente con una entidad en B y viceversa. • Uno a varios (1:N): Una entidad en A se relaciona

con cero o muchas entidades en B. Pero una entidad en B se relaciona con una única entidad en A. • Varios a varios (M:N): Una entidad en A se puede

relacionar con 0 o muchas entidades en B y viceversa.

CLAVES

• Es un subconjunto del conjunto de atributos comunes en una colección de entidades, que permite identificar unívocamente cada una de las entidades pertenecientes a dicha colección. Asimismo, permiten distinguir entre sí las relaciones de un conjunto de relaciones.

CLAVES

• Dentro de los conjuntos de entidades existen los siguientes tipos de claves:

• Superclave: Es un subconjunto de atributos que permite distinguir unívocamente cada una de las entidades de un conjunto de entidades. Si otro atributo unido al anterior subconjunto, el resultado seguirá siendo una superclave.

• Clave candidata: Dada una superclave, si ésta deja de serlo removiendo únicamente uno de los atributos que la componen, entonces ésta es una clave candidata.

• Clave primaria: Es una clave candidata, elegida por el diseñador de la base de datos, para identificar unívocamente las entidades en un conjunto de entidades.

• Ejemplo de superclave• La entidad empleado tiene una clave que consta

del atributo dni porque todos los empleados tienen números de DNI diferentes.• Una determinada entidad puede tener más de

una clave; es decir, puede tener varias claves candidatas.

• Ejemplo de clave candidata• La entidad empleado tiene dos claves candidatas,

la que está formada por el atributo dni y la que está constituida por el atributo nss, teniendo en cuenta que el NSS también será diferente para cada uno de los empleados.

• El diseñador elige una clave primaria entre todas las claves candidatas. En la notación diagramática, la clave primaria se subraya para distinguirla del resto de las claves.• Ejemplo de clave primaria• En el caso de la entidad empleado, podemos

elegir dni como clave primaria.

DIAGRAMA ENTIDAD-RELACIÓN

• Formalmente, los diagramas E-R son un lenguaje gráfico para describir conceptos. Informalmente, son simples dibujos o gráficos que describen la información que trata un sistema de información y el software que lo automatiza.

ENTIDAD

Representa una “cosa” u "objeto" del mundo real con existencia independiente, es decir, se diferencia unívocamente de cualquier otro objeto o cosa, incluso siendo del mismo tipo.Entidad, Ejemplos:• Una persona. (Se diferencia de cualquier otra

persona, incluso siendo gemelos). • Un automóvil. (Aunque sean de la misma marca, el

mismo modelo,..., tendrán atributos diferentes, por ejemplo, el número de motor).

• Una casa (Aunque sea exactamente igual a otra, aún se diferenciará en su dirección).

• Una entidad está descrita y se representa por sus características o atributos. • Por ejemplo, la entidad Persona puede llevar

consigo las características: Nombre, Apellido, Género, Estatura, Peso, Fecha de nacimiento, etc...

ENTIDAD

• Se representa mediante un rectángulo o "caja" etiquetada en su interior mediante un identificador. Ejemplos de entidades habituales en los sistemas de información son: factura, persona, empleado.

ATRIBUTOS

• Los atributos son las propiedades que describen a cada entidad en un conjunto de entidades.• Un conjunto de entidades dentro de una entidad,

tiene valores específicos asignados para cada uno de sus atributos, de esta forma, es posible su identificación unívoca.

ATRIBUTOS

• Atributos, Ejemplos:• A la colección de entidades Alumnos, con el

siguiente conjunto de atributos en común, (id, nombre, edad, semestre), pertenecen las entidades:• (1, Sofía, 18 años, 2) • (2, José, 19 años, 5) • (3, Gabriela, 20 años, 2) • ...

• Cada una de las entidades pertenecientes a este conjunto se diferencia de las demás por el valor de sus atributos. Nótese que dos o más entidades diferentes pueden tener los mismos valores para algunos de sus atributos, pero nunca para todos.

• En particular, los atributos identificativos son aquellos que permiten diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a un alumno de otro es su número de id.

ATRIBUTO

• Se representan mediante un círculo o elipse etiquetado mediante un nombre en su interior. Cuando un atributo es identificativo de la entidad se suele subrayar dicha etiqueta.• Por motivos de legibilidad, los atributos no suelen

representarse en un diagrama entidad-relación, sino que se describen textualmente en otros documentos adjuntos.

TIPOS DE ATRIBUTOS

RELACIÓN

• Describe cierta dependencia entre entidades o permite la asociación de las mismas.• Ejemplo: • Dadas dos entidades "Habitación 502" y "Mark",

es posible relacionar que la habitación 502 se encuentra ocupada por el huésped de nombre Mark.• Una relación tiene sentido al expresar las

entidades que relaciona. En el ejemplo anterior, Un Huésped (entidad), se aloja (relación) en una habitación (entidad).

RELACIONES

• Se representa mediante un rombo etiquetado en su interior con un verbo. Este rombo se debe unir mediante líneas con las entidades (rectángulos) que relaciona.

EJEMPLO DE UN DIAGRAMA ENTIDAD-RELACIÓN

ENTIDADES IS A

• Son relaciones de tipo is a (es un) aquellas en las que una entidad se descompone en entidades especializadas. Hay dos tipos de entidades is a: especializaciones y generalizaciones.• Las especializaciones consisten en que una

entidad se divide en entidades más concretas. La entidad general comparte con las especializadas sus atributos. Se observa una especialización cuando hay ejemplares para los que no tienen sentido algunos de los atributos, mientras que para otros sí.

• Se denomina generalización si se agrupan varias entidades en una o más entidades generales. Se observa una generalización si en varias entidades se observan atributos iguales, lo que significa que hay una entidad superior que posee esos atributos.• En cualquier caso la representación en el modelo

es la misma, se representan con un triángulo que tiene el texto ISA.

EJEMPLO

OFICINISTAS

• En estas relaciones se habla también de herencia, ya que tanto los profesores como los oficinistas como los otros, heredan atributos de la entidad personal (se habla de la superentidad personal y de la subentidad profesores)• Se puede colocar un círculo (como el del número

cero) en lado de la superentidad para indicar que es opcional la especialización, de otro modo se tomará como obligatoria (el personal tiene que ser alguna de esas tres cosas)

• Se puede indicar también exclusividad. Esto ocurre cuando entre varias líneas hacia una relación, las entidades sólo pueden tomar una. Se representa con un ángulo en el diagrama:

OFICINISTAS

• En el diagrama el ángulo indica que el personal sólo puede ser o profesor u oficinista u otros.• No puede ser dos cosas a la vez

EJEMPLO

• Analizaremos un caso práctico de diseño con el modelo ER que corresponde a una base de datos destinada a la gestión de las inscripciones en un conjunto de casas de colonias. El modelo ER de esta base de datos será bastante sencillo e incluirá sólo entidades, atributos e interrelaciones binarias.

• La descripción siguiente explica con detalle los requisitos de los usuarios que hay que tener en cuenta al hacer el diseño conceptual de la futura base de datos:• a) Cada casa de colonias tiene un nombre que la

identifica. Se desea saber de cada una, aparte del nombre, la capacidad (el número de niños que se pueden alojar en cada una como máximo), la comarca donde está situada y las ofertas de actividades que proporciona. Una casa puede ofrecer actividades como por ejemplo natación, esquí, remo, pintura, fotografía, música, etc.

• b) Es necesario tener en cuenta que en una casa de colonias se pueden practicar varias actividades (de hecho, cada casa debe ofrecer como mínimo una), y también puede ocurrir que una misma actividad se pueda llevar a cabo en varias casas. Sin embargo, toda actividad que se registre en la base de datos debe ser ofertada como mínimo en una de las casas.

• c) Interesa tener una evaluación de las ofertas de actividades que proporcionan las casas. Se asigna una calificación numérica que indica el nivel de calidad que tiene cada una de las actividades ofertadas.• d) Las casas de colonias alojan niños que se han

inscrito para pasar en ellas unas pequeñas vacaciones. Se quiere tener constancia de los niños que se alojan en cada una de las casas en el momento actual. Se debe suponer que hay casas que están vacías (en las que no se aloja ningún niño) durante algunas temporadas.

• e) De los niños que se alojan actualmente en alguna de las casas, interesa conocer un código que se les asigna para identificarlos, su nombre, su apellido, el número de teléfono de sus padres y su comarca de residencia.• f) De las comarcas donde hay casas o bien donde

residen niños, se quiere tener registrados la superficie y el número de habitantes. Se debe considerar que puede haber comarcas donde no reside ninguno de los niños que se alojan en un momento determinado en las casas de colonias, y comarcas que no disponen de ninguna casa.

• La figura siguiente muestra un diagrama ER que satisface los requisitos anteriores.• Los atributos de las entidades no figuran en el

diagrama y se listan aparte.

• Los atributos de las entidades que figuran en el diagrama son los siguientes (las claves primarias están subrayadas):

CASA-COLONIAS• nombre-casa, capacidadACTIVIDAD• nombre-actividadNIÑO• código-niño, nombre, apellido, teléfonoCOMARCA• nombre-comarca, superficie, número-habitantes

• A continuación comentamos los aspectos más relevantes de este modelo ER:

1) Una de las dificultades que en ocasiones se presenta durante la modelización conceptual es decidir si una información determinada debe ser una entidad o un atributo. En nuestro ejemplo, puede resultar difícil decidir si comarca se debe modelizar como una entidad o como un atributo.

• A primera vista, podría parecer que comarca debe ser un atributo de la entidad casa-colonias para indicar dónde está situada una casa de colonias, y también un atributo de la entidad niño para indicar la residencia del niño. Sin embargo, esta solución no sería adecuada, porque se quieren tener informaciones adicionales asociadas a la comarca: la superficie y el número de habitantes. Es preciso que comarca sea una entidad para poder reflejar estas informaciones adicionales como atributos de la entidad.

• La entidad comarca tendrá que estar, evidentemente, interrelacionada con las entidades niño y casa-colonias. Observad que de este modo, además, se hace patente que las comarcas de residencia de los niños y las comarcas de situación de las casas son informaciones de un mismo tipo.

• 2) Otra decisión que hay que tomar es si el concepto actividad se debe modelizar como una entidad o como un atributo. Actividad no tiene informaciones adicionales asociadas; no tiene, por lo tanto, más atributos que los que forman la clave. Aun así, es necesario que actividad sea una entidad para que, mediante la interrelación oferta, se pueda indicar que una casa de colonias ofrece actividades.

• Observar que las actividades ofertadas no se pueden expresar como un atributo de casa-colonias, porque una casa puede ofrecer muchas actividades y, en este caso, el atributo no podría tomar un valor único.

• 3) Otra elección difícil, que con frecuencia se presenta al diseñar un modelo ER, consiste en modelizar una información determinada como una entidad o como una interrelación. Por ejemplo, podríamos haber establecido que oferta, en lugar de ser una interrelación, fuese una entidad; lo habríamos hecho así:

• La entidad oferta representada en la figura anterior tiene los atributos que presentamos a continuación:

OFERTA• nombre-casa, nombre-actividad, nivel

• Esta solución no acaba de reflejar adecuadamente la realidad. Si analizamos la clave de oferta, podemos ver que se identifica con nombre-casa, que es la clave de la entidad casa-colonias, y con nombre-actividad, que es la clave de la entidad actividad. Esto nos debe hacer sospechar que oferta, de hecho, corresponde a una asociación o interrelación entre casas y actividades. En consecuencia, reflejaremos la realidad con más exactitud si modelizamos oferta como una interrelación entre estas entidades.

• 4) Finalmente, un aspecto que hay que cuidar durante el diseño conceptual es el de evitar las redundancias. Por ejemplo, si hubiésemos interrelacionado comarca con actividad para saber qué actividades se realizan en las casas de cada una de las comarcas, habríamos tenido información redundante. La interrelación oferta junto con la interrelación situación ya permiten saber, de forma indirecta, qué actividades se hacen en las comarcas.

EJEMPLO: BASE DE DATOS DEL PERSONAL DE UNA ENTIDAD BANCARIA

• Veremos un ejemplo de diseño conceptual de una base de datos mediante el modelo ER.• Se trata de diseñar una base de datos para la

gestión del personal de una entidad bancaria determinada que dispone de muchos empleados y de una amplia red de agencias. La siguiente descripción resume los requisitos de los usuarios de la futura base de datos:

• a) Los empleados se identifican por un código de empleado, y también deseamos conocer su DNI, su NSS, su nombre y su apellido. Será importante registrar su ciudad de residencia, considerando que hay ciudades donde no reside ningún empleado.

• b) Interesa saber en qué ciudades están ubicadas las diversas agencias de la entidad bancaria. Estas agencias bancarias se identifican por la ciudad donde están y por un nombre que permite distinguir las agencias de una misma ciudad.• Se quiere tener constancia del número de

habitantes de las ciudades, así como de la dirección y el número de teléfono de las agencias. Se debe considerar que la base de datos también incluye ciudades donde no hay ninguna agencia.

• c) Un empleado, en un momento determinado, trabaja en una sola agencia, lo cual no impide que pueda ser trasladado a otra o, incluso, que vuelva a trabajar en una agencia donde ya había trabajado anteriormente. Se quiere tener constancia del historial del paso de los empleados por las agencias.• d) Los empleados pueden tener títulos

académicos (aunque no todos los tienen). Se quiere saber qué títulos tienen los empleados.

• e) Cada empleado tiene una categoría laboral determinada (auxiliar, oficial de segunda, oficial de primera, etc.). A cada categoría le corresponde un sueldo base determinado y un precio por hora extra también determinado. Se quiere tener constancia de la categoría actual de cada empleado, y del sueldo base y el precio de la hora extra de cada categoría.

• f) Algunos empleados (no todos) están afiliados a alguna central sindical. Se ha llegado al pacto de descontar de la nómina mensual la cuota sindical a los afiliados a cada central. Esta cuota es única para todos los afiliados a una central determinada. Es necesario almacenar las afiliaciones a una central de los empleados y las cuotas correspondientes a las diferentes centrales sindicales.

• g) Hay dos tipos de empleados diferentes:• Los que tienen contrato fijo, cuya antigüedad queremos conocer.• Los que tienen contrato temporal, de los cuales nos interesa saber las fechas de inicio y finalización de su último contrato.

• Si un empleado temporal pasa a ser fijo, se le asigna un nuevo código de empleado; consideraremos que un empleado fijo nunca pasa a ser temporal. Todo lo que se ha indicado hasta ahora (traslados, categorías, afiliación sindical, etc.) es aplicable tanto a empleados fijos como a temporales.

• h) Los empleados fijos tienen la posibilidad de pedir diferentes tipos preestablecidos de préstamos (por matrimonio, por adquisición de vivienda, por estudios, etc.), que pueden ser concedidos o no. En principio, no hay ninguna limitación a la hora de pedir varios préstamos a la vez, siempre que no se pida más de uno del mismo tipo al mismo tiempo. Se quiere registrar los préstamos pedidos por los empleados, y hacer constar si han sido concedidos o no. Cada tipo de préstamo tiene establecidas diferentes condiciones; de estas condiciones, en particular, nos interesará saber el tipo de interés y el periodo de vigencia del préstamo.

• La siguiente figura muestra un diagrama ER que satisface los requisitos anteriores:

• Los atributos de las entidades que figuran en el diagrama son los siguientes (las claves primarias se han subrayado):

EMPLEADO• código-emplado, dni, nss, nombre, apellidoFIJO (entidad subclase de empleado)• código-empleado, antigüedadTEMPORAL (entidad subclase de empleado)• código-empleado, fecha-inicio-cont, fecha-final-

cont

CIUDAD• nombre-ciudad, número-habAGENCIA (entidad débil: nombre-agencia la identifica parcialmente,• se identifica completamente con la ciudad de

situación)• nombre-agencia, dirección, teléfonoTÍTULO• nombre-título

CATEGORÍA• nombre-categ, sueldo-base, hora-extraCENTRAL-SINDICAL• central, cuotaTIPO-PRÉSTAMO• código-préstamo, tipo-interés, período-vigenciaFECHA• fecha

• A continuación, comentaremos los aspectos que pueden resultar más complejos de este modelo ER:• 1) La entidad agencia se ha considerado una

entidad débil porque su atributo nombre-agencia sólo permite distinguir las agencias situadas en una misma ciudad, pero para identificar de forma total una agencia, es necesario saber en qué ciudad está situada. De este modo, la interrelación situación es la que nos permite completar la identificación de la entidad agencia.

• 2) La interrelación petición es ternaria y asocia a empleados fijos que hacen peticiones de préstamos, tipos de préstamos pedidos por los empleados y fechas en las que se hacen estas peticiones.

• 3) El lado de la entidad fecha se conecta con “muchos” porque un mismo empleado puede pedir un mismo tipo de préstamo varias veces en fechas distintas. La entidad fijo se conecta con “muchos” porque un tipo de préstamo determinado puede ser pedido en una misma fecha por varios empleados. También la entidad tipo-préstamo se conecta con “muchos” porque es posible que un empleado en una fecha determinada pida más de un préstamo de tipo diferente.

• 4) El atributo concedido/no indica si el préstamo se ha concedido o no. Es un atributo de la interrelación porque su valor depende al mismo tiempo del empleado fijo que hace la petición, del tipo de préstamo pedido y de la fecha de petición.

• 5) La interrelación traslado también es una interrelación ternaria que permite registrar el paso de los empleados por las distintas agencias. Un traslado concreto asocia a un empleado, una agencia donde él trabajará y una fecha inicial en la que empieza a trabajar en la agencia. El atributo de la interrelación fecha-fin indica en qué fecha finaliza su asignación a la agencia (fecha-fin tendrá el valor nulo cuando un empleado trabaja en una agencia en el momento actual y no se sabe cuándo se le trasladará). Observad que fecha-fin debe ser un atributo de la interrelación. Si se colocase en una de las tres entidades interrelacionadas, no podría ser un atributo univaluado.

• Conviene observar que esta interrelación no registra todas y cada una de las fechas en las que un empleado está asignado a una agencia, sino sólo la fecha inicial y la fecha final de la asignación. Es muy habitual que, para informaciones que son ciertas durante todo un periodo de tiempo, se registre en la base de datos únicamente el inicio y el final del periodo.

• Notese que la entidad agencia se ha conectado con “uno” en la interrelación traslado, porque no puede ocurrir que, en una fecha, un empleado determinado sea trasladado a más de una agencia.

• 6) Finalmente, comentaremos la generalización/especialización de la entidad empleado. Los empleados pueden ser de dos tipos; se quieren registrar propiedades diferentes para cada uno de los tipos y también se requieren algunas propiedades comunes a todos los empleados. Por este motivo, es adecuado utilizar una generalización/especialización.

EJEMPLO ARTICULOS-PEDIDOS

• Una base de datos para una pequeña empresa debe contener información acerca de clientes, artículos y pedidos.

• Hasta el momento se registran los siguientes datos en documentos varios:

• • Para cada cliente: Número de cliente (único), Direcciones de envío (varias por cliente), Saldo, Límite de crédito (depende del cliente, pero en ningún caso debe superar los 3.000.000 pts), Descuento.

• • Para cada artículo: Número de artículo (único), Fábricas que lo distribuyen, Existencias de ese artículo en cada fábrica, Descripción del artículo.

• • Para cada pedido: Cada pedido tiene una cabecera y el cuerpo del pedido.

• La cabecera está formada por el número de cliente, dirección de envío y fecha del pedido. El cuerpo del pedido son varias líneas, en cada línea se especifican el número del artículo pedido y la cantidad.

• Además, se ha determinado que se debe almacenar la información de las fábricas.

• Sin embargo, dado el uso de distribuidores, se usará: Número de la fábrica (único) y Teléfono de contacto.

• Y se desean ver cuántos artículos (en total) provee la fábrica.

• También, por información estratégica, se podría incluir información de fábricas alternativas respecto de las que ya fabrican artículos para esta empresa. • Nota: Una dirección se entenderá como Nº, Calle,

Comuna y Ciudad. • Una fecha incluye hora. • Se pide hacer el diagrama ER para la base de

datos que represente esta información.

MODELO RELACIONAL

• El modelo relacional se ha establecido actualmente como el principal modelo de datos para las aplicaciones de procesamiento de datos. Ha conseguido la posición principal debido a su simplicidad que facilita el trabajo del programador en comparación con otros modelos como el de red y el jerárquico

MODELO RELACIONAL

• Una base de datos relacional consiste en un conjunto de tablas, a cada una de las cuales se le asigna un nombre exclusivo. Cada tabla tiene una estructura parecida o derivada de los diagramas entidad relación, cada fila de la tabla representa una relación entre un conjunto de valores.

MODELO RELACIONAL

EL PROCESO DE DISEÑO

• Establecer una metodología para el diseño de las bases de datos que se van a crear, permite revisar y repetir la secuencia de pasos que se siguen durante su creación, lo cual conlleva a una mejora continua del proceso y desarrollo de un producto final, en este caso una base de datos.

EL PROCESO DE DISEÑO

A continuación se enumeran los pasos necesarios para este diseño:• Especificar el objetivo de la base de datos• Definir las tablas que se necesitan en la base de datos• Especificar qué campos se requieren en cada tabla• Especificar el campo clave o clave principal de cada

tabla• Definir el tipo de dato que se va a manejar en cada

campo• Ajustar todos los datos• Definir las relaciones entre las tablas• Introducir los datos y crear todos los objetos necesarios

SISTEMA GESTOR DE BASES DE DATOS

• (SGBD-DBMS:DataBase Management System)• En toda la organización se suelen distinguir, tres

niveles de gestión: operacional, táctico y estratégico, de modo que el sistema de información estará integrado por tres subsistemas estructurados jerárquicamente y que se corresponden con cada uno de estos tres niveles.


• La base de datos, como depósito único de datos para toda la organización, debe ser capaz de integrar los distintos subsistemas y aplicaciones atendiendo a las necesidades de los usuarios en los tres niveles, siendo el SGBD el que suministra la interfaz entre el conjunto de los datos y los usuarios


Nivel Estratégico Elaboración de Planes Objetivos Generales

Nivel Táctico Control de Gestión Objetivos Específicos

Nivel Operacional Tareas administrativas

Base Común

De Datos

S G B D


• Se puede definir el Sistema de Gestión de la Base de Datos (SGBD) como un conjunto coordinado de programas, procedimientos, lenguajes, etc. que suministra a los distintos tipos de usuarios los medios necesarios para describir y manipular los datos almacenados en la base, garantizando su seguridad.

• Las operaciones típicas que debe realizar un SGBD pueden resumirse en aquellas que afectan a la totalidad de los datos (o a todos los registros de un determinado tipo) y las que tienen lugar sobre registros concretos

• Sobre el conjunto de la base• • Creación• • Reestructuración• • Consulta a la totalidad

• Sobre registros concretos• • Inserción• • Borrado• • Modificación• • Consulta selectiva

Las funciones esenciales de un SGBD son:• La Función de definición o descripción• La Función de manipulación• La Función de control o utilización

LA FUNCIÓN DE DEFINICIÓN O DESCRIPCIÓN

• La función de definición (también llamada descripción) debe permitir al diseñador de la base especificar los elementos de datos que la integran, su estructura y las relaciones que existen entre ellos, las reglas de integridad semántica, etc., así como las características de tipo físico y las vistas lógicas de los usuarios.

LA FUNCIÓN DE MANIPULACIÓN

• Una vez descrita la base de datos, es preciso cargar los datos de las estructuras previamente creadas, con lo que la base de datos estará ya dispuesta para su utilización. Los usuarios tendrán necesidad de recuperar la información (consultar la base de datos), o bien de actualizarla porque se hayan producido cambios en los datos.

LA FUNCIÓN DE CONTROL O UTILIZACIÓN

• Esta función reúne todas las interfaces que necesitan los diferentes usuarios para comunicarse con la base y proporciona un conjunto de procedimientos para el administrador.

• En especial, esta función debe integrar una serie de instrumentos que faciliten las tareas del administrador. En la mayoría de los SGBD existen funciones de servicio, como cambiar la capacidad de los archivos, obtener estadísticas de utilización, cargar archivos, etc., y principalmente las relacionadas con la seguridad física (copias de seguridad, rearranque en caso de caída del sistema, etc.) y de protección frente a accesos no autorizados.

ESQUEMA DE ACCESO A LOS DATOS DE UN SGBD O DBMS

• Los datos son responsabilidad del DBMS, por lo que cualquier acceso debe ser realizado por éste. Lógicamente el DBMS va a acabar comunicándose con el Sistema Operativo ya que el acceso a los ficheros de datos implica utilizar funciones del sistema operativo.• A continuación se observa cómo se produce la

interacción completa entre un proceso de usuario y un sistema gestor de bases de datos. Los pasos explicados del esquema son:

Diseño de Bases de Datos.pptx

Documents

Transcript of Diseño de Bases de Datos.pptx