TEMA 1. SISTEMAS DE
ALMACENAMIENTO DE LA INFORMACIÓN
1.1 Ficheros:
Un ordenador almacena muchos
tipos d información, datos administrativos, contables, música, imágenes, películas,
paginas web etc. Toda esta información esta almacenada en los dispositivos de
almacenamiento del ordenador es decir, discos duros, pens, DVD etc. Toda esta información se organiza
mediante ficheros o archivos.
Por lo tanto los ficheros son estructuras
d información q crean el SO para poder almacenar datos. Tienen un nombre de una
extensión, q determina el formato o tipo de la información q contienen.
Tipos d ficheros y formatos: el
formato o tipo d fichero determinan la forma d interpretar la información q
contiene, ya q en definitiva lo único q se almacena en un fichero es un ristra
de 0000001111111 (bits) de forma q es necesaria su interpretación para dar
sentido a la información que se almacena. Todos estos datos se ordenan según el
formato y el sistema operativo o la
utilidad que trate ese fichero debe conocer ese formato para poder representar
la información.
Tradicionalmente los ficheros se
han clasificado d muchas formas según su contenido (texto y binario) según su organización (secuencial, directa,
interesado) o según su utilidad (ficheros maestros, ficheros históricos,
ficheros d movimientos).
La organización de un fichero
dicta la forma en q se han d acceder a los datos, así los datos d un fichero
con organización secuencial están dispuestos siguiendo una secuencia ordenada
es decir unos detrás d otros. Se caracterizan por tener q recorrer todos los
datos anteriores para llegar a uno concreto. Los ficheros d organización
directa permiten acceder a un dato en concreto sin necesidad d acceder a todos
los anteriores. Finalmente los d organización interesada acceden a los datos
consultando un índice, es decir una estructura d datos q permiten acceder a la
información rápidamente, simulando la forma en q el índice d un libro facilita
el acceso a sus contenidos. Por otro lado, la utilidad d un fichero indica q
use se va hacer d el, por ejemplo puede contener datos fundamentales para una
organización, como los datos d los clientes, que se almacenan en un fichero
principal llamado maestro. Si hay variaciones (altas modificaciones o bajas d
clientes) en los ficheros maestros se almacenan en los llamados ficheros d
movimientos q posteriormente se enfrentan con los maestros para incorporar las
modificaciones. Finalmente cuando existen datos q ya no son necesarios para su
procesa diario pasan a formar parte d los ficheros históricos. Hoy en día estas
dos ultimas clasificaciones han quedado casi en des uso. Por ejemplo desde la
aparición desde las bases de datos modernas, ya no se clasifican los ficheros
según su utilidad u organización, actualmente podemos clasificar los ficheros
desde dos puntos de vista:
1-según su
contenido (texto o datos binarios ).
2-según su tipo
(imágenes ejecutables videos etc.).
Código ASCII tablas d caracteres UNICODE ficheros binarios
y sus extensiones ficheros de texto y utilización, formatos enriquecidos rtf ps
,text, formatos comprimidos, ficheros de configuración d Windows.
Base de datos: es una colección de información
perteneciente a un mismo contexto, q esta almacenada d forma organizada en
ficheros.
Generalmente los ficheros que
componen una base d datos son d tipo binario, puesto q la información q hay
almacenada en ellos debe tener un formato adecuado a las aplicaciones q pueda
acceder a ella. El software del gestor d base d datos oracle guarda la
información en múltiples tipos d ficheros llamados datafiles, tempfiles,
logfiles, acces guarda toda la información d una base d datos en ficheros con extensión
mdb y actualmente accdb .Una base d datos eksta organizada mediante tablas, q
almacenan información relacionada con algún objeto o suceso. Estas tablas se
relacionan formando vínculos o relaciones entre ellas, q ayudan a mantener la
información de los diversos objetos d forma ordenada y coherente.
Cada una d esas tablas es una
estructura q se parece a las hojas d calcula, pues esta dispuesta mediante
filas y columnas. De este modo, cada fila almacena un registro a cada fila
almacena un registro con tantos campos
como columnas tenga la tabla. Por ejemplo se podría tener una tabal d empleados
donde cada fila o registro es un empleado d la empresa y cada columna o campo
representa un trozo d información sobre cada empleado, el nombre o el num. d
teléfono.
Dato: es un
trozo d información concreta sobre algún concepto o suceso. Por ejemplo 1996 número
q representa un año d nacimiento d una persona. Los datos se caracterizan por
pertenecer a un tipo. Tipo de dato: el tipo de dato indica la naturaleza del
campo. Así se pueden tener datos numéricos son aquellos con los q se puede
realizar cálculos aritméticos. Datos alfa numéricos contienen caracteres y dígitos
numéricos. Campo es un nombre para toda una familia d datos. Cada campo
pertenece a un tipo de dato. Por ejemplo el campo fecha nacimiento representa las fechas d nacimiento d las
personas q hay en la tabla. Este campo pertenece al tipo d dato fecha al campo
también se le llama columna.
Registro:
colección de datos pertenecientes aun mismo concepto o suceso. Por ejemplo los
datos de una persona: Nif, año d nacimiento, nombre, dirección etc. A los
registros también se le llaman duplas o filas.
Campo clave: es un
campo especial que identifica d forma única a cada registro de la tabla.
Consulta: Es una
instrucción para hacer peticiones a una BBDD. puede ser una búsqueda simple de
un registro especifico o una solicitud para seleccionar todos los registros que
satisfagan un conjunto de criterios.
Informe: Listado ordenado
de los campos y registros seleccionados en un formato facil de leer, ejemplo,
un informe de las facturas impagadas del mes de Enero ordenado por nombre de
cliente.
USOS DE LAS BBDD
Están en cualquier tipo de sistema informático, sus
usos mas frecuentes son:
1- BBDD Administrativas son las utilizadas para
registrar clientes, pedidos, facturas, productos, uso empresarias, toda la
información estará integrada en una unica BBDD.
2- BBDD contables, se utilizan para crear balances,
estados de perdidas y ganancias , declaraciones de hacienda, ámbito
empresarial.
3- BBDD científicas: recogen datos climáticos y medio
ambientales, químicos , geológicos, etc.
WDCC, (World Data Climate Center) almacena 6144
Terabites .
4- BBDD para motores de búsquedas, los buscadores
tiene BBDD gigantescas donde almacenas información sobre todas las web.
CONFIGURACIONES
Almacenas
datos de configuración de un sistema informático como por ejemplo el registro de
Windows, bibliotecas, ejemplo, Amazon, los sensos, los programas antivirus,
videojuegos, usos militares, etc.
EVOLUCION Y TIPOS
DE BBDD.
La clasificación de las BBDD en tipos , esta ligada a
su evolución histórica. Según ha ido avanzando la tecnología, ( hardware ) las
BBDD han mejorado cambiando la forma de representar y extraer la información.
En la década de los 50, se inventan las cintas
magnéticas, que solo podían ser leídas de forma secuencial. Estas cintas,
almacenaban ficheros con registros que se procesaban secuencial mente. Estos
sistemas se conocen como aplicaciones basadas en sistemas de ficheros, y
constituyen la generación cero de las BBDD, pues, ni siquiera entonces existía
el concepto de BBDD.
En la década de los 60, se generaliza el uso de discos
magnéticos cuya característica ppal es que se podía acceder de forma directa a
cualquier parte de los ficheros sin tener que acceder a todos los datos
anteriores.Con esta tecnología aparecen las primeras BBDD de tipos jerárquicas
y en red.
UNIDADES DE
MEDIDAS
Bit
|
(1,0)
|
Binary Digit
|
Byte
|
8 bits
|
|
Kilobyte
|
KB
|
1024bytes
|
Megabyte
|
MB
|
1024KB
|
Gigabyte
|
GB
|
1024MB
|
Terabyte
|
TB
|
1024GB
|
Petabyte
|
PB
|
1024TB
|
Exabyte
|
EB
|
1024PB
|
Zetabyte
|
ZB
|
1024EB
|
Yottabyte
|
YB
|
1024ZB
|
Codd
cientifico Ingles de IBM, publica en 1970 un articulo donde define el modelo
relacional ( tipo de BBDD) nacen de esta forma las BBDD relacionales o segunda
generacion de BBDD.
Larry
Ellison, fundador de ORACLE, se inspiro en este articulo para
desarrollar el famoso motor de BBDD ORACLE, que comenzo como un proyecto para la CIA.
Hoy en dia el modelo relacion de Codd, sigue siendo el
más utilizado.
En 1980 IBM lanza su motor de BBDD DB2. años despues
IBM crea SQL ( Structure Query Lenguage ) es un potente lenguaje de consultas.
A finales de 1990, IBM y ORACLE incorporán a sus BBDD,
la capacidad de manipular objetos creando asi, las BBDD orientadas a a objetos.
BBDD Distribuidas, comienzan a utilizarce con la
aparicion de internet.
SISTEMA GESTOR DE BBDD SGBD
Es un conjunto de herramientas que facilitan la
consulta, uso y actulización de una BBDD.
Un jemplo gestor de Software de BBDD es ORACLE, que
incopora un conjunto de herramientos Software que son capaces de estructurar en
multiples discos duros los ficheros de una BBDD, prmitiendo el acceso a sus
datos tanto a partir de herramientas grafícas, como a partir de potentes
lenguajes de programación.
FUNCIONES DE UN SGBD
Casi todos los que existen actualmente en el mercado
tienen:
1- Permiten a los usuarios almacenar datos, acceder a
ellos y actualizarlos de una forma sencilla.
2- Garantizán la integridad de los datos, es decir, no
permiten operaciones que dejen los datos incompletos o incorrectos.
3- Integran junto con el S.O, un sistema de seguridad
que garantiza el acceso a la información solo a aquellos usuarios que dispongan
de autorización.
4- Permiten la concurrencia (multiacceso al mismo
dato).
5- Permite el uso de transacciones. (conjunto de
operaciones que se realizan de forma simultanea como si fueran una sola orden).
TEMA 2
Representación
del problema:
Una base de datos representa la
información contenida en algún dominio del mundo real. El diseño de base de
datos consiste en extraer todos los datos relevantes de un problema, por
ejemplo: saber que datos están implicados en el proceso e facturación de una
empresa que venden vehículos agrícolas o , que datos son necesarios para llevar
el control veterinario de los animales de un zoológico.
Para extraer esos datos se debe
realizar un análisis en profundidad del dominio del problema y saber de esta
forma que datos son esenciales para a base de datos y descartar los que no se han
de utilidad. Una vez extraídos los datos esenciales comienza el proceso de modelización esto es construir mediante una herramienta de
diseño de BD, un esquema que exprese con total exactitud todos los datos que el
problema requiere al almacenar.
Típicamente, los informáticos
analizan un problema a través de diversas reuniones con los futuros usuarios
del sistema. Generalmente el problema no solo se resuelve poniendo una BD a
disposición de usuario, sino también un conjunto de aplicaciones software que
automaticen el acceso a los datos y su gestión. De estas reuniones se extrae el
documento mas importante del análisis de un Sistema informático, el documento
de especificación de requisitos
software. A partir de este documento se extrae toda la información
necesaria para la modelización de los datos.
Modelo de datos:
La modelización es una representación del problema que nos sirve para
asimilar toda la información y generar un esquema donde este identificados y
generar un mapa donde este identificados todos los elementos de la BD.
Modelo Entidad/Relación. Fue propuesto por Petter P.Chen a mediados de
los 70 para la representación de los datos y el establecimiento de las relaciones
existentes ente ellos. Tiene una notación muy sencilla, precisamente esta
sencilla notación permite representar en mundo real de forma que el usuario
pueda validar si el modelo propuesto se ajusta perfectamente a la resolución
del problema.
Los componentes que utiliza este modelo son:
- Entidad: Es cualquier objeto o concepto sobre el que se recoge información
(cosa, persona, concepto abstracto o sucesos) . Se representan mediante
rectángulos y su nombre aparece en el interior (generalmente en singular). Un
nombre de entidad solo puede aparecer una vez en el diagrama ejemplo. Hay 2
tipos de entidades: Fuertes(Es aquella que existe por meritos propios, un
ejemplo típico es la existencia de 2 entidades para la representación de un
pedido. Por un lado, la entidad pedido representa información genérica sobre el
pedido como la fechaPedido, fechaEnvio, el estado…) y débiles(Es aquella cuya
existencia depende de la existencia de otra entidad, se representan mediante un
rectángulo doble). Por otro lado, la entidad de detalle de pedido representa
los artículos y unidades vendidas. En este caso línea de pedido es una entidad
débil, porque si borramos el pedido implica la eliminación de línea de pedido
asociada a la primera.
- Ocurrencia de una entidad: Es una unidad de conjunto que representa la
entidad, por ejemplo: si tenemos la entidad coche esa entidad tendrá varias
instancias como por ejemplo el vehiculo SEAT Ibiza con matricula 1122 FHD color
negro.
- Relación: Es una asociación entre 2 o mas entidades. Cada relación tiene un
nombre que describe su función, tiene que ser un nombre descriptivo, se
representan gráficamente mediante Rombos y su nombre en el interior.
Generalmente este nombre corresponde a un verbo.
Las relaciones están clasificadas según su grado (es el numero
de entidades que participan en la relación) Grado 2
Cuando hay 3 entidades es de Grado 3.
Unarias Grado 1: Es una relación donde una entidad participa mas de
una vez en la relación con distintos papeles
Relaciones N-arias: Son cuando tienen grado mayor de 3. son aquellas
cuando participan mas de 3 entidades. Aparecen en muy rara ocasión, ya que
generalmente se puede descomponer en varias de grado 2 o 3
PARTICIPACION
La participación de una ocurrencia de una entidad, indica, mediante
una pareja de números, el mínimo y máximo numero de veces que puede aparecer en
la relación asociada a otra ocurrencia de entidad. Las posibles participaciones
son:
La
cardinalidad De una relación se calcula a través de las
participaciones de sus ocurrencias en ella. Se toma el número máximo de
participaciones de cada una de ls identidades en la relación.
De esta manera se
clasifican las siguientes cardinalidades:
1:1 Esta cardinalidad específica que una
entidad A puede estar vinculada mediante una relación a una y solo una
ocurrencia de otra identidad B. A su vez, una ocurrencia de la entidad B solo
puede estar vinculada a una ocurrencia de la entidad A.
Ejemplo: Un
empleado solo puede ser jefe o solo puede dirigir un departamento, y un
departamento solo puede tener un jefe.
1:n àQue una entidad A puede estar vinculada mediante una relación a varias ocurrencias de otra entidad B. sin embargo una ocurrencia de la entidad B, solo puede estar vinculada a una ocurrencia de la entidad A.
Ejemplo: Un
representante gestiona las carreras de varios actores y un actor solo puede
tener un representante
n:n à Esta
relación especifica que una entidad A puede estar vinculada mediante una
relación a varias ocurrencias de la entidad B, y a su vez una ocurrencia de la
entidad B puede estar vinculada a varias ocurrencias de la entidad A
CARDINALIDAD DE LAS RELACCIONES REFLEXIVAS
En las relaciones
reflexivas la misma entidad juega 2 papeles distintos en la relación.
Para calcular su
cardinalidad hay que extraer las participaciones según los 2 roles existentes.
Ejemplo: En la
relación reflexiva “es jefe”, la entidad empleados aparece con 2 roles. El
primer rol es empleado como jefe y el segundo rol es el empleado como el
subordinado. Así se puede calcular las participaciones en la relación
preguntando:
-
¿Cuántos
subordinados puede tener un jefe?(1,n)
-
¿Cuántos
jefes puede tener un subordinado?(0,1)
ATRIBUTOS Y DOMINIOS
Los atributos de
una entidad, son las características o propiedades que la definen como
identidad. Por ejemplo, para representar la entidad hotel son necesarias sus
características, es decir el número de plazas disponibles, su dirección,
ciudad, categoría. Se representa mediante elipses conectadas directamente a la
entidad.
ATRIBUTO CLAVE
El atributo que
aparece subrayado se le denomina clave, y designa un atributo que no puede
repetir ninguna ocurrencia de la entidad. Se dice que este atributo identifica
unívocamente a una entidad. Todas las entidades fuertes deben tener al menos un
atributo clave. Tengas en cuenta que una entidad pueda formar la clave mediante
varios atributos, en este caso, se dice que la clave de la entidad es una clave
compuesta. Si la clave esta formada por un único atributo se dice que es
atómica.
1.1
ATRIBUTOS
DE RELACIÓN
Un atributo de relación
es aquel que es propio de una relación y que no puede ser cedido a las
entidades que intervienen en la relación.
DOMINIOS. Cada
uno de los atributos que tiene una entidad, pertenece a un dominio. El dominio
representa la naturaleza del dato, es decir, si es un número entero, una cadena
de caracteres o un número real.
Numero
entero, no tiene parte decimal. 1 – 2 – 3 – 4 -1500
Numero
Real, Incluye enteros y decimales, positivos y negativos.: 28.3, 5, -250.36.
Cadena de
caracteres: Combinación de letras y/o Números.
Numero de
teléfono, es una cadena de caracteres por la naturaleza del dato, no operamos
con el.
Incluso
naturaleza más compleja como una fecha, o una hora.
Por ejemplo los
siguientes atributos de la entidad empleado pertenecen a los sgtes dominios:
ATRIBUTO
|
DOMINIO
|
LONGITUD
|
DNI
|
Cadena de
caracteres
|
10
|
NOMBRE
|
Cadena de
caracteres
|
50
|
FECHA_NACIMIENTO
|
Fecha
|
|
DIRECCION
|
Cadena de
caracteres
|
100
|
SUELDO
|
Numero Real
|
|
NUMERO DE HIJOS
|
Numero Entero
|
|
DEPARTAMENTO
|
Cadena de
caracteres/ Tipo especial según opciones de
departamentos.(rrhh,admin.,contabilidad-informática)
|
|
Si un dominio se
especifica mediante el tipo de datos como en el caso del DNI, Nombre o Fecha de
Nacimiento, se dice que se define por INTENSIÓN.
Si se especifica
mediante un conjunto de valores, como en el dominio departamentos, que puede
tener los valores:
RRHH,
Administración, Informática, o Contabilidad. La definición del Dominio es por
EXTENSION.
TIPOS DE
ATRIBUTOS
Se pueden
clasificar los atributos según las sgtes restricciones:
1-Atributos obligatorios / opcionales:
Atributo
Obligatorio, Es un
atributo que debe tomar un valor obligatoriamente, no quiere decir que se ponga
o no en la BD,
significa que el valor nunca puede estar vacío.
Atributo
Opciones; Puede no tomar
un valor por que se ha desconocido en un momento determinado. En este caso el
atributo tiene un valor nulo.
2-Atributos Compuestos / Simples o
Atómicos:
Atributos
Compuestos, Es aquel que
puede descomponerse en atributos mas sencillos, por ejemplo hora-de-salida, se
puede descomponer en 2, horas y minutos.
3-Atributos univaluados / Atributos
Multivaluados:
Atributos
Univaluados; El atributo
toma un único valor: Edad, nombre.
Atributos
Multivaluados: Pueden
tomar varios valores: Teléfono, Autor de un libro.
4-Atributos derivados
Son aquellos cuyo
valor se puede calcular a través de otros atributos, ejemplo: el atributo de
Edad, se puede calcular a partir de la fecha de nacimiento de una persona.
Para distinguir
si es simple, compuesto univaluado, se representa según la siguiente tabla:
Compuesto Elipse
doble, se especifican los atributos a continuación.
Multivaluado,
Elipse Doble
Opcional la línea
es discontinua
Derivado, el
trazo de la elipse es discontinuo.
Esta Notación no
es totalmente estandar.
Justifica
que tipo de atributos son los sgtes atributos de la entidad persona
·
Fecha
de nacimiento (24/11/1976) Atomico
·
Lugar
de Nacimiento ( Zaragoza) univaluado
·
Edad
(34) derivado -univaluado
·
Es
mayor de edad ( si ) derivado
·
DNI
( 55582739-A univaluado
·
TELEFONOS
( 925884721, 657662531) multivaluado
·
APELLIDOS
(garca perez) compuesto
LAS ENTIDADES DEBILES
Dependen de una
entidad fuerte mediante una relación, la relación que une ambas entidades
también es débil, puesto que también desaparece si desaparece la entidad
fuerte.
En estos casos la
relación puede ser de dos tipos:
1-Dependencia
de existencia: Este tipo
de dependencia expresa que las ocurrencias de una entidad débil, no tienen
ningún sentido en la BBDD
sin la presencia de las concurrencias de la entidad fuerte con a que están
relacionadas.
a.Las
transacciones que se dan en una CCC no tiene sentido si la CCC no esta activa las
transacciones desaparecen.
Transacciones con
dependencia de existencia, E
2- Dependencia
de Identificación: Este
tipo se produce cuando además de la dependencia de existencia, la entidad
débil, necesita a la fuerte para poder crear una clave, de tal manera que pueda
completar la identificación de sus ocurrencias.
Una empresa que
crea aplicaciones software:
a)
la
compañía se identifica por su nombre “Microsoft”.
b) Las
aplicaciones se identifican por su nombre comercial “ Office”
c) Cada
compañía de software pone un nombre a cada una de sus aplicaciones.
Ejemplo de
entidad débil con dependencia de IDENTIFICACION (I)
Ejercicio: Decir que tipo de relación de
Dependencia tienen las siguientes entidades:
1- Un Toto (Entidad Débil) Pertenece a una
ganadería (Entidad fuerte). Al toro se le identifica por un número y el nombre
de su ganadería, puesto que puede haber varios toros con el mismo número pero
pertenecientes a distintas ganaderías.
2En el acceso al parking de una empresa un
empleado (entidad fuerte) tiene un vehiculo ( entidad débil)
Vamos a indicar una serie de guías para crear un diagrama E/R
1.
Primero
y no poco importante es leer varias veces el problema hasta tener una idea
global.
2.
Obtener
una lista inicial de candidatos a entidades, relaciones y atributos.
Se realiza siguiendo los sgtes consejos:
- Identificar las entidades suelen ser aquellos nombres comunes que son importantes para el desarrollo del problema: Eje, empleado – vehículo – pintor.
- No hay que obsesionarse, en los primeros pasos por distinguir las entidades fuertes de las débiles.
- Si es trivial, se toma nota de aquellas que parezcan claramente entidades débiles. De lo contrario se apuntan como entidades sin especificar si son fuertes o débiles.
- Extraer los atributos de cada entidad, identificando aquellos que puedan ser clave. Se suelen distinguir por ser adjetivos asociados a un nombre común (que ha sido seleccionado como una entidad). Ejem. Color que es un adjetivo, puede ir asociado a la entidad vehiculo.
- Además se puede establecer el tipo de atributo seleccionando si es opcional, obligatorio, multivaluado, compuesto o derivado. Si es compuesto se indica su composición, si es derivado, se indica como se calcula.
- Es bastante útil apuntar sinónimos, utilizados para el atributo, para eliminar redundancias.
- Identificar los atributos de cada relación. Se suelen distinguir al igual que los de la entidad por ser adjetivos, teniendo en cuenta que para que sean de una relación solo deben ser aplicables a la relación y no a ninguna de las entidades relacionadas.
- Es posible que los nombres comunes contengan muy poca info. Y no sea posible incluirlos como entidades. En este caso se pueden seleccionar como atributos de otra entidad que ya teníamos. Eje. El autor de un libro puede ser una entidad, pero solo si se dispone del nombre del autor, no tiene sentido incluirlo como una entidad con un solo atributo. Pondríamos como atributo el autor a la entidad LIBRO.
MODELO ENTIDAD RELACION AMPLIADA
El modelo entidad
relación extendido o ampliado incorpora, todos los elementos del modelo E/R, incluyendo además los conceptos de
subclase, súper clase, junto a los conceptos de especialización y
generalización:
- Generalización y especialización: una entidad E, es una generalización de un grupo de entidades (E1, E2, En, ) si cada ocurrencia de cada una de estas entidades, es también una ocurrencia de E.
Todas las propiedades de
la entidad genérica E, son heredadas por las sub-entidades.
Las sub-entidades son especializaciones
de las entidad general, se puede decir que las sub-entidades o subclases tienen
una relación del tipo “ES UN”, con
la entidad padre o superclase.
La relación de
generalización, se representa mediante un triangulo isósceles, pegado por la base
a la entidad superclase.
En el ejemplo anterior
Empleado, es la súper clase y los directivos, comerciales y técnicos son las
subclases.
En la relación se
adjunta, un atributo que indica como debe interpretarse la relación de la
superclase con las subclases
-TIPOS DE ESPECIALIZACION
Se puede agregar mas semántica al diagrama
E/R extendido combinando los sgtes
tipos de especialización:
- Especialización exclusiva: Se representa:
En este caso cada una de las ocurrencias
de la superclase solo puede materializarse en una de las especializaciones;
ejemplo, si un empleado es directivo, no puede ser un técnico o un comercial.
- Especialización Inclusiva: Se produce cuando las ocurrencias de las superclase pueden materializarse a la vez en varias ocurrencias de las subclases. En este caso el empleado directivo, podría ser Tb. técnico y comercial. Se representa sin el arco
- Especialización Total: Se produce cuando la entidad superclase tiene que materializarse obligatoriamente en una de las especializaciones, se representa así: añadiendo un circulo en la base del triangulo.
- Especialización parcial: La entidad superclase no tiene por que materializarse en una de las especializaciones (es opcional).
COMO CALCULAR LA CARDINALIDAD DE
RELACIONES NO BINARIAS
Para calcular la
cardinalidad de una relación ternaria se tomara una de las 3 entidades y se
combinara con las otras dos. A continuación,
se calcula la participación de la entidad en la combinación de las otras
dos. Posteriormente se hará lo mismo con las otras dos entidades finalmente.
Tomando los máximos de las participaciones de cada una de las entidades se
genera la cardinalidad de la relación.
TRANSFORMACION DE UN DIAGRAMA ENTIDAD- RELACION A UN MODELO RELACIONAL
Para realizar esta
transformación se siguen las siguientes reglas:
- TRANSFORMACION DE ENTIDADES FUERTES: Para cada entidad A, entidad fuerte, con atributos (A1, A2… AN) se crea una tabla A con el (nombre en plural), con N columnas correspondientes a los atributos de A, donde cada fila de la tabla A corresponde a una ocurrencia de la entidad A. La clave primaria de la tabla A la forman los atributos claves de la entidad A
Tablas:
CATEGORIAS (Código, Descripción)
PRODUCTOS (Id, Nombre, Precio,
Descripción)
Para cada entidad débil D, con atributos
Cd1, Cd2… Cd n, donde Cd3 hasta Cd n
son los atributos clave. Se crea una tabla D con los siguientes atributos:
Cd1,Cd2..Cdn
mas los atributos Cf1, Cf2 hasta Cf n,
correspondiente a los atributos Clave de la entidad fuerte F.
Si solo tiene dependencia de asistencia la
clave primaria de la tabla D, será la unión de los tributos clave de la entidad
D. Si la entidad débil además tiene una dependencia de identificación la clave
primaria de la tabla D será la unión de los atributos de la entidad débil D y
la entidad fuerte F.
Transacciones (Tipo, Cantidad, Código, Nº
Cuenta)
Cuentas Bancarias (Nº Cuenta, Saldo)
TRANSFORMACION LAS RELACIONES
Por cada relación R entre entidades E1,
E2…En, la clave de E i, es C i = a i 1+a
i 2+…+ai N , como regla general para las relaciones, se
crea una tabla con todos los campos claves de las entidades relacionadas y los
atributos de la relación. La clave primaria de la tabla generada es la suma de
los atributos claves de las entidades relacionadas y cada clave incorporada a
la tabla será una clave foránea que referencia a la tabla de la que se importa.
Ejemplo
Tenemos una relación ternaria con dos
entidades con clave compuesta. AULA y ASIGNATURA y otra ESTUDIANTE que tiene
una clave simple.
AULAS (Situación, Planta, Numero)
ESTUDIANTES (Nº matricula, nombre,
dirección)
ASIGNATURAS (nombre, ciclo,
descripción)
ESTUDIOS (Numero, Planta, Nº Matricula,
Nombre, Ciclo, Hora)
No siempre se aplica esta regla general,
para crear una tabla por cada relación. Generalmente se pueden encontrar las
siguientes excepciones a la regla general.
1-Regla: Relaciones con cardinalidad 1:N En este caso no se crea
una tabla para la relación, si no que se añade a la tabla de la entidad que
actúa con participación máxima n la
clave de la entidad que actúa con participación máxima 1 (como clave foránea). Si además la relación tuviera atributos
estos se importarían también a la entidad que actúa con participación máxima n.
Ejemplo Regla 1:
ACTORES (código, Nombre Artístico, Nombre Real, Nº Licencia,
Contrato)
REPRESENTANTES (Nº Licencia,
Nombre)
2-Regla: Relaciones reflexivas con
cardinalidad 1:N: En este caso tampoco se crea una tabla para la relación hay que crear
una tabla con el nombre de la entidad añadiendo otra vez la clave cambiada de
nombre :
Ejemplo Regla 2:
En este ejemplo el empleado solo puede
tener un jefe. Un jefe puede serlo de uno o varios empleados.
EMPLEADOS (DNI, nombre, DNI_jefe)
3-Regla Relaciones 1:1 Este tipo de relaciones
tampoco generan tabla, el paso a tablas se realiza de forma muy parecida a las
relaciones 1:N. En este caso se tiene la libertad de poder incorporar la clave
de una de las dos entidades a la otra.
-ACTORES
(Código, Nombre, Código Personaje)
PERSONAJES
(Nombre, Película, Código)
-ACTORES (Código, Nombre)
PERSONAJES
(Código Actor, Nombre, Película, Código)
-ACTORES (Código, Nombre, Código
Personaje)
PERSONAJES
(Nombre, Película, Código, Código Actor)
NORMALIZACION
OBJETIVO:
Es conseguir basándonos
en las relaciones obtenidas en la transformación del modelo conceptual y aplicando
unas normas concretas un conjunto de relaciones optimo que una vez implementado
físicamente:
1-
Evite redundancias superfluas.
2-
Aminore el espacio requerido para el almacenamiento.
3-
Evite problemas de integridad
4-
Forme una estructura flexible y fácil de mantener.
DEPENDENCIAS FUNCIONALES
Dependencia Funcional: Se dice que un atributo
B depende funcionalmente de otro A de la misma relación si para todo valor de
A, se cumple q a cada valor de A le corresponde no mas de un valor de B.
Se representa así:
B depende funcionalmente de A
Ejemplo: En una relación donde tenemos los datos de los alumnos de un
instituto, con los sgtes atributos: DNI Alumno, curso, grupo, aula, edificio.
Podemos decir que el atributo edificio depende funcionalmente del atributo aula,
ya que cada aula esta ubicada en un edificio concreto o lo que nos decía la
definición formal para cada valor de aula solo existe un valor de edificio
(suponemos que los nombres de las aulas son distintos en cada uno de los
edificios que forma el instituto, y lo representamos de la siguiente forma.
“B NO DEPENDE FUNCIONALMENTE DE A“
Las dependencias también
se pueden expresar respecto a combinaciones o atributos, en este caso la
representación seria:
A cada par de valores A y
B le corresponde un valor de C. se dice que C tiene una dependencia funcional
del conjunto de A y B.
En el ejemplo anterior
podemos decir que el atributo AULA, depende funcionalmente de la unión de los
atributos CURSO y GRUPO. Ya que para cada par de valores de curso y grupo, solo
existen un valor de AULA
Dependencia Funcional
Completa:
Se dice que un atributo C, tiene dependencia funcional completa de un grupo de
atributos X de la misma relación, si C depende funcionalmente de X, pero no de
ningún subconjunto obtenido de los posibles atributos que forman X.
La notación usada para
indicar que un atributo C tiene dependencia funcional completa de un grupo de
atributos X (formado por los atributos Ay B), sera:
En el ejemplo el conjunto
formado por los atributos CURSO y GRUPO, con respecto al atributo AULA, es un
ejemplo de dependencia funcional completa, ya que, para cada CURSO existen
varias aulas y para cada GRUPO también, solo para el par completo el valor de
AULA es unico.
DEPENDENCIA TRANSITIVA
Se han A,B,C 3 atributos
(o grupos de atributos) de una relación. Si B depende funcionalmente de A y C
de B, pero A no depende funcionalmente de B, se dice que C depende
transitivamente de A.
En el ejemplo podemos
encontrar una dependencia funcional transitiva de EDIFICIO con respecto DNI
Alumno, ya que se cumple lo siguiente.
PASOS A SEGUIR EN LA
NORMALIZACION:
Las relaciones deben
cumplir con unas restricciones que han sido definidas en las distintas formas
normales. En un principio CODD, definió las 3 primeras formas normales.
Posteriormente la tercera forma normal fue revisada por BOYCE y el mismo CODD
aumentando el número de restricciones y pasándose a llamar la forma normal de
BOYCE Y CODD (FNBC). Posteriormente en los años 70, Fagin, definió la 4 y 5 forma
normal.
PRIMERA FORMA NORMAL:
Definición formal: Una relación se dice
que esta en primero forma normal, si el valor de los dominios de los atributos
es único, o lo que es lo mismo cada atributo es único.
Definición menos
drastica: Se
dice que una relación esta en primera forma normal si contiene para cada
intersección de fila-columna un solo valor y no un conjunto de ellos.
Ejemplo: Se desea hacer
un análisis de los datos del área de venta de una empresa. La única entidad que
un analista poco experimentado intuye es la entidad pedidos. Los atributos que
ve en ella son: Código pedido, fecha pedido, Código cliente, nombre cliente,
ciudad cliente, teléfono cliente, código
producto, descripción producto, precio unitario producto, código del
proveedor, teléfono proveedor, y cantidad pedida de producto.
Codigo Pedido
|
Fecha
|
Codigo Cliente
|
Nombre cliente
|
Ciudad
|
Tel. Cliente
|
Codigo Prod
|
Descrip. Producto
|
Precio Unitario
|
Cod Prov
|
Tel Prov
|
Cant
|
1
|
12/03/2002
|
32
|
Juan Perez
|
Madrid
|
999999
|
10
|
Caja
Galletas
|
3 €
|
2
|
444
|
5
|
45
|
Zumo Piña
|
1 €
|
66
|
555
|
10
|
||||||
2
|
37358
|
25
|
Antonio Lopez
|
Sorilla
|
777777
|
33
|
Detergente
|
12 €
|
32
|
2222
|
3
|
95
|
Vino Dulce
|
2 €
|
21
|
111
|
2
|
||||||
78
|
Champú
|
3 €
|
32
|
222
|
1
|
Esta tabla no se encuentra en primera forma Normal.
Haremos el paso a primera
forma normal: Una vez que identifiquemos los atributos que tienen varios
valores para uno concreto de la clave, se formara con ellos una nueva relación
y se eliminaran de la antigua. La clave principal de la nueva relación estará
formada por la concatenación de uno o
varios de sus atributos y la clave principal de la antigua.
PEDIDOS: Código pedido, Fecha pedido,
Código Cliente, Nom cliente, Ciudad cliente, Teléfono Cliente
LINESA DE PEDIDOS: Código pedido, Código producto,
desc producto, cod proveedor, precio unitario, teléfono prov, cantidad.
Pedidos
|
Codigo Pedido
|
Fecha Pedido
|
Codigo Cliente
|
Nombre Cliente
|
Ciudad Cliente
|
Telefono Cliente
|
1
|
12/03/2002
|
32
|
Juan Perez
|
Madrid
|
999999
|
|
2
|
12/04/2002
|
25
|
Antonio
|
Lopez
|
777777
|
Lineas de Pedido
|
Codigo Pedido
|
Codigo producto
|
Des. Producto
|
Precio unitario
|
Cod. Proveedor
|
Telefono proveedor
|
cantidad
|
1
|
10
|
caja
galletas
|
3 €
|
1
|
444
|
5
|
|
1
|
45
|
zumo piña
|
1 €
|
66
|
555
|
10
|
SEGUNDA FORMA NORMAL: Cuando todos los campos dependen totalmente de
la clave
Definición formal: Una relación esta en
2FN si esta en 1FN y cada atributo suyo distinto de los que componen una calve
candidata, tiene una dependencia funcional completa de dicha clave candidata.
Definición menos drástica:
Una relación
esta en 2FN, si esta en 1FN y cada uno de sus atributos depende de toda la
clave
Ejemplo: en el caso
anterior observamos que la relación líneas de pedidos todos los atributos menos
el atributo cantidad-pedida, no tienen una dependencia funcional de la clave,
sino que la tienen de una parte de la clave principal, del código del producto.
Líneas de Pedido
|
Codigo Pedido
|
Codigo producto
|
Des. Producto
|
Precio unitario
|
Cod. Proveedor
|
Telefono proveedor
|
cantidad
|
1
|
10
|
caja
galletas
|
3 €
|
1
|
444
|
5
|
|
1
|
45
|
zumo piña
|
1 €
|
66
|
555
|
10
|
El código de producto puede ser considerado clave, puesto que con solo
dar el código de producto nos da todos los demás datos excepto la cantidad.
Una vez identificados los
atributos que no dependen completamente de la clave, si no solo de parte de
ella, se formara con ellos otra relación y se quitaran de la antigua. La clave
principal de la nueva tabla estará formada por la parte de la antigua de la que
dependan totalmente.
RELACION PRODUCTOS ( Código producto, Descripción
producto, Precio unitario, Cod Proveedor, Telefono Proveedor)
LINEAS DE PEDIDOS ( Código pedido, Código de producto, cantidad)
Relación productos
|
Codigo Producto
|
Des. Producto
|
Precio unitario
|
Cod. Proveedor
|
Teléfono proveedor
|
10
|
caja
galletas
|
3 €
|
1
|
444
|
|
45
|
zumo piña
|
1 €
|
66
|
555
|
Líneas de Pedido
|
Código Pedido
|
Código producto
|
cantidad
|
1
|
10
|
5
|
|
1
|
45
|
10
|
La tabla Pedidos también
se puede descomponer en dos tablas.
RELACION CLIENTES: (Código
cliente, nombre cliente, ciudad cliente, teléfono cliente)
PEDIDOS: (Código
pedido, Fecha pedido, Código cliente)
Pedidos
|
Código Pedido
|
Fecha Pedido
|
Código Cliente
|
1
|
12/03/2002
|
32
|
|
2
|
12/04/2002
|
25
|
Relación Clientes
|
Código Cliente
|
Nombre Cliente
|
Ciudad Cliente
|
Teléfono Cliente
|
32
|
Juan Perez
|
Madrid
|
999999
|
|
25
|
Antonio
|
Lopez
|
777777
|
TERCERA FORMA NORMAL
Una relación esta en 3FN
si esta en 2FN y cada uno de sus atributos depende solo de la clave.
En el ejemplo observamos
que la tabla productos, el atributo teléfono de proveedor no depende de toda la
clave principal sino del atributo código de proveedor.
PRODUCTOS: (Código
producto, Desc. Producto, precio unitario, cod proveedor, telf proveedor)
Relacion productos
|
Codigo Producto
|
Des. Producto
|
Precio unitario
|
Cod. Proveedor
|
Telefono proveedor
|
10
|
caja
galletas
|
3 €
|
1
|
444
|
|
45
|
zumo piña
|
1 €
|
66
|
555
|
Una vez identificados los
atributos que dependen de otro atributo distinto de la clave, se formara con
ellos otra relación y se quitaran de la antigua. La calve principal de la nueva
relación Será el atributo del cual depende.
RELACION PRODUCTOS: (Código
producto, Descripción producto, precio unitario)
PROVEEDORES: (Código
proveedor, Teléfono proveedor)
Relacion productos
|
Codigo Producto
|
Des. Producto
|
Precio unitario
|
10
|
caja
galletas
|
3 €
|
|
45
|
zumo piña
|
1 €
|
PROVEEDORES
|
Cod. Proveedor
|
Telefono proveedor
|
1
|
444
|
|
66
|
555
|
No hay comentarios:
Publicar un comentario