Upload
erika-yohana-plaza-veloza
View
601
Download
0
Embed Size (px)
Citation preview
FORO 3
UNIDAD III: PARTE A: DISEÑO DE BASES DE DATOS, MODELOS RELACIONALES Y NORMALIZACIÓN Por: Erika Plaza.
Universidad del Quindío. Facultad de Ciencias Humanas y Bellas Artes. Ciencia de la Información y la Documentación, Bibliotecología y Archivística. Bases de Datos.
FORO 3
1. ¿Cuál es el modelo de entidad relación que propone Richard Baker en la técnica de modelado de datos? Explicar o dar ejemplos.
El modelo entidad relación identifica asuntos de importancia para una organización a los que se llamará entidades, las propiedades de esos asuntos llamadas atributos y como se relacionan entre sí (relación). Los objetivos de este modelo son: Facilitar un modelo específico de acuerdo a las necesidades de
información de la organización. Desempeñarse como un marco de trabajo para el desarrollo de sistemas
nuevos o mejorados. Proporcionar un modelo independiente de cualquier almacenamiento de
datos y método de acceso, facilitando la toma de decisiones objetivas en relación con las técnicas de implementación y la coexistencia con sistemas más antiguos.
Para desarrollar el modelo entidad relación es necesario tener en cuenta los siguientes aspectos: Dato: recurso clave. El dato hace parte de la evolución de la organización; es una ventaja estratégica para una entidad el control de estos recursos de información. Compromiso de la dirección: Es esencial para el desarrollo del modelo contar con la participación y compromiso de la dirección para confirmar los requisitos de información que requiere. Convenciones: Es imprescindible incluir convenciones específicas y bien estructuradas, estándares y directrices, incluyendo los conceptos de normalización de datos. Definición mínima: Es importante definir cualquier información o concepto de una sola forma y luego realizar las asociaciones para los objetos relacionados. De esta forma se debe definir solo una vez la cosa llamada “pedido de compra” y posteriormente relacionarlo con el departamento, los productos, las funciones de autorización, etc. Independencia de datos: Se deben definir los requisitos de información de manera independiente a cualquier método de almacenamiento y de acceso, lo que permitirá una visión creativa y objetiva de la empresa y del diseño Subsiguiente.
Tomado de:
https://books.google.com.co/books?id=hbOTo05ddxAC&pg=PA11&hl=es&source=gbs_toc_r&cad=3#v=onepage&
q&f=false
Elementos del modelo entidad relación:
Entidad: objetos relevantes y de interés para una organización. Ejemplo:
Cliente, empleado, pedido, sucursal, factura, etc. Relación: Asociación entre dos entidades Atributo: Característica importante para una organización.
Las entidades son representadas por cajas de bordes redondeados, no es importante su tamaño. Cada entidad solo aparece una vez en un modelo y debe tener un único nombre, que debe ser escrito en mayúsculas y en singular. En caso de existir un sinónimo para la entidad se puede escribir entre paréntesis o separado por una barra oblicua. Las entidades pueden aparecer varias veces dentro del modelo o tener varias peticiones. Se pueden presentar dos tipos de entidades:
Entidades débiles: No pueden existir sin la existencia de otras entidades, por ejemplo, los Detalles de una Factura,
Entidades fuertes: Tienen existencia propia.
Ejemplos de entidades:
– Personas: Alumno, Pasajero, Profesor, Cliente – Instituciones: Banco, Empresa, Universidad – Unidades organizacionales: Departamento, Sucursal, Planta, Línea – Clasificaciones, agrupaciones y jerarquías: Tipo, Clase, Marca,
Grupo, Género – Documentos: Factura, Pedido, Orden, Cheque
Objetos (físicos o abstractos): Material, Producto, Asignatura, Habilidad.
Las relaciones por su parte establecen una relación bidireccional, significativa y nombrable, entre dos entidades que no necesariamente deben ser distintas, lo que se denomina “relación recursiva”.
De esta forma establecen una acción o relación entre las entidades. Cada dirección de una relación presenta: Nombre (leyenda) Opcionalidad: Línea punteada (puede) o continua (debe). Grado o cardinalidad: un punto (.), que significa uno o el símbolo ( ) que significa muchos. (Moreno, 2015)
Convenciones para la representación:
Una línea que une las dos entidades relacionadas Los nombres de las relaciones en el extremo de cada entidad y en
minúscula Opcionalidad:
Obligatoria: Línea continua Opcional: Línea discontinua
Cardinalidad o grado “Pata de gallina” (Crow’s foot*): Muchos Punto (fin de la línea continua o discontinua): Uno.
Es importante evitar leyendas como “relacionado con” o “asociado con”, porque no aportan información sobre la relación. No colocar leyendas con verbos en infinitivo (“tener”, “estar”, “poseer”, etc.) La lectura de acuerdo con la notación presentada quedaría mal. (Moreno, 2015)
Atributos Son las características, propiedades que describen a una entidad, identifican, califican, cuantifican, clasifican o expresan el estado de la entidad. Los nombres deben ser claros, completos y preferiblemente sin incluir el nombre de la entidad (Moreno, 2015) El nombre de los atributos se escribe en minúscula dentro de la caja de la entidad Se recomienda descomponerlos hasta su mínima expresión semántica. Aunque es posible tenerlos, se evitarán atributos generados a partir de otros (problemas de redundancia y consistencia). Ejemplo: En una entidad ESTUDIANTE con un atributo fecha de nacimiento NO es necesario tener un atributo edad, si se tienen FACTURAS y sus DETALLES de productos vendidos NO es necesario tener un atributo para el total de productos vendidos en la factura.
Atributos Identificadores Identificador (único) de una entidad: Conjunto de atributos y/o relaciones que identifican de manera única una entidad. Ejemplos: Entidad con un solo identificador: ALUMNO con atributos cédula, nombre y año nacimiento. Entidad con varios identificadores candidatos: ELEMENTO QUÍMICO con número, símbolo, nombre, temp_ebullición. Entidad con un identificador compuesto por dos atributos*: VEHÍCULO donde la placa se representa con dos atributos así: letras, dígitos, color, modelo. Entidad con un identificador compuesto por un atributo y una relación: CUENTA1con número cuenta (atributo) y cod_sucursal (relación), saldo. Entidad con un identificador compuesto por un atributo y dos relaciones: Ej.: PEDIDO2 con la fecha (atributo), cod_producto (relación) y el cod_proveedor (relación), nro_unidades Convenciones: Se les antepone el símbolo # Se coloca una línea paralela a la entidad cerca del punto terminal de la
relación. Si hay varios identificadores candidatos, se selecciona uno y se dejan los
demás como secundarios o alternativos*. Se pueden definir identificadores artificiales o surrogados para evitar un
identificador compuesto por muchos atributos
1 Dos sucursales pueden tener números de cuenta iguales, pero una misma sucursal no puede tener dos
números de cuenta iguales. 2 Es decir, aquí a un mismo proveedor se le puede pedir el mismo.
2. ¿Amplié el concepto sobre que es un modelo relacional?
El modelo está basado en el concepto matemático de la relación, se fundamenta en
la teoría de “normalización de las relaciones”, que permite eliminar el
comportamiento anormal de las relaciones, luego de actualizaciones, así como el
“control de la redundancia de datos” (Gutierrez, 2011).
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.
Atributo: columna en una relación identificada por un nombre.
Tupla / registro: fila en una tabla o relación que contiene un conjunto de valores
acordes al esquema de la relación (sus columnas y dominios).
Esquema de una relación (o tabla): nombre de la relación seguido de la lista de
sus atributos con sus dominios.
Dominio: Conjunto de valores, que puede tomar un área. Por ejemplo:
Colores = {´rojo´, ´verde´, ´azul´}
Marcas = {´fiat´, ´toyota´, ´ford´, ´Honda´}
Esquema
Un esquema contiene 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 qué
tipo de información podrá ser almacenada dentro de ella; en otras palabras, el
esquema contiene los metadatos de la relación. 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.
Relación: Subconjunto del producto cartesiano de una lista de dominios.
Producto cartesiano: es el cruce de las variables de un domino con las de otro
dominio. Por ejemplo:
Colores = {´rojo´, ´verde´, ´azul´}
Marcas = {´Fiat´, ´Toyota´, ´Ford´}
Se cruzan todas las variables de Marca con las todas las variables de color
Luego se puede tomar un Subconjunto del producto cartesiano de los dominios:
Marca Color
Fiat Rojo
Fiat Verde
Fiat Azul
Toyota Rojo
Toyota Verde
Toyota Azul
Ford Rojo
Ford Verde
Ford Azul
R1={(‘Fiat´, ´verde´), (´Toyota´, ´azul´), (´Ford´, ´rojo´)}
R2= {(´rojo´, ´honda´)}, o bien R3= {}
R1 Marca Color
Fiat Verde
Toyota Azul
Ford Rojo
Instancias
Se puede definir como el contenido de una tabla en un momento dado, pero también
es válido referirnos a una instancia cuando trabajamos o mostramos únicamente un
subconjunto de la información contenida en una relación o tabla, como por ejemplo:
Ciertos caracteres y números (una sola columna de una sola fila).
Algunas o todas las filas con todas o algunas columnas
Cada fila es una tupla. El número de filas es llamado cardinalidad.
El número de columnas es llamado aridad o grado.
Marca Color
Fiat Rojo
Fiat Verde
Fiat Azul
Toyota Rojo
Toyota Verde
Toyota Azul
Ford Rojo
Ford Verde
Ford Azul
Relación
3. ¿Quién diseño la base de datos Oracle?
Los ingenieros de Sillicon Valley, Larry Ellison, Bob Miner y Ed Oates fundan en 1977 una empresa de consultoría llamada Software Development Laboratories (SDL) y tiempo después obtienen un contrato con la CIA para diseñar un sistema especial de bases de datos con código clave "Oracle". Ellison y Miner habían leído un artículo en la revista IBM Journal of Research and Development donde se describía una versión preliminar del lenguaje SQL, basado en el artículo de E. F. Codd donde propone el modelo relacional: "A Relational Model of Data for Large Shared Data Banks". En 1978 y buscando la coherencia con sus objetivos empresariales, SDL cambia de nombre a Relational Software Incorporated (RSI). La compañía busca tener un producto que fuese compatible con el SQL de IBM, y además enfocarse en un mercado de las minicomputadoras, abarcando así un segmento que en ese momento a IBM no le interesaba. En 1982 RSI cambia su nombre a Oracle Systems Corporation, y poco después se acorta a su definitivo Oracle Corporation, el siguiente año empieza a comercializar Oracle V3, agregando el manejo de transacciones a través de las instrucciones COMMIT y ROLLBACK. De hecho, el producto es recodificado en C lo que permite expandir las plataformas de ejecución para incluir los entornos Unix, cuando hasta aquí era solo sobre Digital VAX/VMS. De esta manera Oracle se convierte en la Primera Base de Datos Diseñada para Grid Computing, como un sistema de gestión de base de datos relacional fabricado por Oracle Corporation. Oracle es básicamente un herramienta cliente/servidor para la gestión de base de datos la gran potencia que tiene y su elevado precio hace que solo se vea en empresas muy grandes y multinacionales, por norma general. Oracle Corporation: es una de las mayores compañías de software del mundo. Sus productos van desde bases de datos (Oracle) hasta sistemas de gestión. Cuenta además, con herramientas propias de desarrollo para realizar potentes aplicaciones, como Oracle Designer. Características de Oracle Desarrollado sobre Oracle Database: Oracle Content Database ha sido diseñada para que las organizaciones puedan controlar y gestionar grandes volúmenes de contenidos no estructurados en un único repositorio con el objetivo de reducir los costes y los riesgos asociados a la pérdida de información.
4. ¿Quién definió las tres primeras formas normales?
Edgar F. Codd originalmente definió las tres primeras formas normales (1NF, 2NF,
y 3NF). Estas formas normales se han resumido como requiriendo que todos los
atributos no-clave sean dependientes en "la clave, la clave completa, y nada excepto
la clave".
En la teoría de bases de datos relacionales, las formas normales (NF) proporcionan
los criterios para determinar el grado de vulnerabilidad de una tabla a
inconsistencias y anomalías lógicas. Cuanta más alta sea la forma normal aplicable
a una tabla, menos vulnerable será a inconsistencias y anomalías. Cada tabla tiene
una "forma normal más alta" (HNF): por definición, una tabla siempre satisface los
requisitos de su HNF y de todas las formas normales más bajas que su HNF;
también por definición, una tabla no puede satisfacer los requisitos de ninguna forma
normal más arriba que su HNF. Las formas normales son aplicables a tablas
individuales; decir que una base de datos entera está en la forma normal n es decir
que todas sus tablas están en la forma normal n
5. ¿Cuáles son las 12 reglas de Edgar Frank Codd del modelo relacional de base de datos? -Explicarla.
Son un sistema de reglas (numeradas del 0 al 12) propuestas por Edgar F. Codd,
del modelo relacional para las bases de datos, diseñado para definir qué requiere
un sistema de administración de base de datos.
Codd se percató de que existían bases de datos en el mercado las cuales decían
ser relacionales, pero lo único que hacían era guardar la información en las tablas,
sin estar estas tablas literalmente normalizadas; entonces éste publicó 12 reglas
que un verdadero sistema relacional debería tener aunque en la práctica algunas
de ellas son difíciles de realizar. Un sistema podrá considerarse "más relacional"
cuanto más siga estas reglas.
Regla 0: El sistema debe ser relacional, base de datos y administrador de
sistema. Ese sistema debe utilizar sus facilidades relacionales (exclusivamente)
para manejar la base de datos.
Regla 1: La regla de la información, toda la información en la base de datos es
representada unidireccionalmente, por valores en posiciones de las columnas
dentro de filas de tablas. Toda la información en una base de datos relacional
se representa explícitamente en el nivel Lógico exactamente de una manera:
con valores en tablas.
Regla 2: la regla del acceso garantizado, todos los datos deben ser accesibles
sin ambigüedad. Esta regla es esencialmente una nueva exposición del requisito
fundamental para las llaves primarias. Dice que cada valor escalar individual en
la base de datos debe ser lógicamente direccionable especificando el nombre
de la tabla, la columna que lo contiene y la llave primaria.
Regla 3: Tratamiento sistemático de valores nulos, el sistema de gestión de
base de datos debe permitir que haya campos nulos. Debe tener una
representación de la "información que falta y de la información inaplicable" que
es sistemática, distinto de todos los valores regulares.
Regla 4: catálogo dinámico en línea basado en el modelo relacional, el sistema
debe soportar un catálogo en línea, el catálogo relacional debe ser accesible a
los usuarios autorizados. Es decir, los usuarios autorizados deben poder tener
acceso a la estructura de la base de datos (catálogo).
Regla 5: la regla comprensiva del sublenguaje de los datos, el sistema debe
soportar por lo menos un lenguaje relacional que:
1. Tenga una sintaxis lineal.
2. Puede ser utilizado de manera interactiva.
3. Soporte operaciones de definición de datos, operaciones de
manipulación de datos (actualización así como la recuperación),
seguridad e integridad y operaciones de administración de
transacciones.
Regla 6: regla de actualización, todas las vistas que son teóricamente
actualizables deben ser actualizables por el sistema.
Regla 7: alto nivel de inserción, actualización y borrado, permitiendo el sistema
realizar manipulación de datos de alto nivel, es decir, sobre conjuntos de tuplas.
Esto significa que los datos no solo se pueden recuperar de una base de datos
relacional de filas múltiples y/o de tablas múltiples, sino también pueden
realizarse inserciones, actualización y borrados sobre varias tuplas y/o tablas al
mismo tiempo (no sólo sobre registros individuales).
Regla 8: independencia física de los datos, los programas de aplicación y
actividades del terminal permanecen inalterados a nivel lógico cuando quiera
que se realicen cambios en las representaciones de almacenamiento o métodos
de acceso.
Regla 9: independencia lógica de los datos, los cambios al nivel lógico (tablas,
columnas, filas, etc.) no deben requerir un cambio a una solicitud basada en la
estructura. La independencia de datos lógica es más difícil de lograr que la
independencia física de datos.
Regla 10: independencia de la integridad, las limitaciones de la integridad se
deben especificar por separado de los programas de la aplicación y se
almacenan en la base de datos. Debe ser posible cambiar esas limitaciones sin
afectar innecesariamente las aplicaciones existentes.
Regla 11: independencia de la distribución, la distribución de las porciones de
la base de datos a las varias localizaciones debe ser invisible a los usuarios de
la base de datos. Los usos existentes deben continuar funcionando con éxito:
1. cuando una versión distribuida del SGBD se introdujo por primera vez
2. cuando se distribuyen los datos existentes se redistribuyen en todo el
sistema.
Regla 12: la regla de la no subversión, si el sistema proporciona una interfaz de
bajo nivel de registro, a parte de una interfaz relacional, que esa interfaz de bajo
nivel no se pueda utilizar para subvertir el sistema, por ejemplo: sin pasar
por seguridad relacional o limitación de integridad. Esto es debido a que existen
sistemas anteriormente no relacionales que añadieron una interfaz relacional,
pero con la interfaz nativa existe la posibilidad de trabajar no relacionalmente.
BIBLIOGRAFIA
Barker, Richard. El modelo entidad-relación. CASE*METHODTM. Universidad Pontifica de Salamanca. Madrid, España. Publicado 1990. [En línea] [Citado 23 de octubre de 2015]. Disponible en internet: https://books.google.com.co/books?id=hbOTo05ddxAC&pg=PA11&hl=es&source=gbs_toc_r&cad=3#v=onepage&q&f=false
García. Emiliano. Forma normal 123. ACADEMIA.EDU. [en línea] [Citado 23 de octubre de 2015]. Disponible en internet: http://www.academia.edu/8400539/Forma_normal_1_2_3 ORACLE. ¿Qué es Oracle?. [En línea] [Citado 23 de octubre de 2015]. Disponible en internet: https://iessanvicente.com/colaboraciones/oracle.pdf WIKIPEDIA. Modelo relacional. Modificado 22 de octubre de 2015. [En línea] [Citado 23 de octubre de 2015]. Disponible en internet: https://es.wikipedia.org/wiki/Modelo_relacional WIKIPEDIA. 12 Reglas de Codd. Modificada 19 de octubre de 2015. [En línea] [Citado 23 de octubre de 2015]. Disponible en internet: https://es.wikipedia.org/wiki/12_reglas_de_Codd