tipos de datos - eduarmandov.files.wordpress.com€¦ · tipos de datos capítulo 5 – pág. 93...

Tipos de Datos Capítulo 5 – Pág. 91

Capí tu lo

5 Tipos de Datos

Objetivos

Al final de este módulo, Ud. será capaz de: • Describir los tipos de datos • Seleccionar los tipos de datos apropiados para las columnas de las bases de datos


Este módulo describe los tipos de datos y como asignarlos a los atributos.


Hay ocho categorías de tipos de datos disponibles. Character Almacena cualquier combinación de letras, números y símbolos. Numeric Almacena datos numéricos. Hay varios tipos numéricos de datos

diseñados para acomodar diferentes clases de datos numéricos. Serial Almacena números enteros secuenciales asignados

automáticamente por el servidor de base de datos. Se usan comúnmente para columnas de llaves primarias.

Date Almacena fechas calendario. Money Almacena montos monetarios. Datetime Almacena puntos específicos en el tiempo. Interval Almacena valores que representan un período. Variable length Almacena datos de longitud variable. Existen varios tipos de

datos de longitud variable para almacenar diferentes clases de datos de longitud variable.

Cada columna en una tabla tiene asignado uno y solo un tipo de dato.

Nota:


Las columnas CHAR o CHARACTER almacenan cualquier combinación de letras, números y símbolos. Los datos almacenados en estas columnas pueden ser nombres, direcciones, números de seguro social, números de teléfono, nombres de proyectos, o cualquier otra información que sea letras, números, símbolos de puntuación o símbolos de otros tipos.

En muchas aplicaciones, CHAR es el tipo de datos más común y toma la mayor parte de espacio del disco. La máxima longitud de una columna CHAR en una base de datos es de 32,767 bytes, pero la mayoría de las columnas CHAR están entre 1 y 500 bytes. Si Ud. está usando otros, la máxima longitud es de 32,511 bytes. La columnas CHAR son de longitud fija. Si una columna de caracteres es definida con un ancho de 400 bytes, los datos para tal columna tomarán ese monto de espacio en disco, aún cuando los datos sean menores de 400 caracteres. Nota:

Los números pueden ser almacenados en una columna CHAR, pero no pueden ser usados en algunas operaciones aritméticas. Los números que son necesarios para cálculos deben ser almacenados en columnas numéricas. NCHAR almacena cualquier string nativo de letras, números y símbolos. Los datos tipo NCHAR son reconocidos solamente cuando Native Languaje Support (NLS) está activo por medio de la variable de ambiente DBNLS. Cuando NLS está habilitado, las columnas de datos CHAR son tratadas como columnas de datos NCHAR.


Existen cinco tipos de datos para números y cada uno es asignado a diferente tipo de número. NO es posible almacenar caracteres o símbolos en una columna numérica. De cualquier manera, los signos más (+) y menos (-) pueden ser introducidos para mostrar donde los números son positivos o negativos. Nota:

Las columnas numéricas son de longitud fija, al igual que las columnas CHAR. Las siguientes páginas describen cada uno de los tipos de datos numéricos.


Números esteros son almacenados en columnas INTEGER, INT y SMALLINT. Si usted sabe que un número excederá +/- 32,767, debe asignarle un tipo de dato INTEGER. Usted puede ahorrar dos bytes de espacio en disco usando el tipo de dato SMALLINT. Un INTEGER requiere cuatro bytes, mientras que un SMALLINT requiere solo dos. Probablemente esto no sea significativo en pequeñas aplicaciones, pero puede haber una substancial diferencia en aplicaciones grandes. Usted puede convertir un SMALLINT a INTEGER sin perder datos. Ejemplos: INTEGER Números de facturas SMALLINT Números de piezas, números de pedidos


Las columnas FLOAT y SMALLFLOAT almacenan números binarios de punto flotante. Estos números son usados en cálculos científicos y de ingeniería. La precisión para estos tipos de datos es como sigue: FLOAT Doble precisión, 14-16 dígitos significativos SMALLFLOAT Precisión sencilla, 7-8 dígitos significativos Las columnas FLOAT pueden almacenar el doble de dígitos que las columnas SMALLFLOAT. Las columnas FLOAT no necesariamente almacenan números grandes; almacenan números con mayor precisión. Nota: Es posible almacenar hasta 8 dígitos significativos para columnas SMALLFLOAT y 16 dígitos significativos para columnas FLOAT. Esto depende del tipo de chip de punto flotante usado dentro del sistema. El almacenamiento interno también depende del tipo de chip de punto flotante usado. Ejemplos:

FLOAT Precisión del espejo principal del telescopio Hubble SMALLFLOAT Raíces cuadradas

Nota:


Las columnas definidas como de DOBLE PRECISION se comportan igual que las columnas FLOAT. El tipo de dato REAL es sinónimo de SMALLFLOAT.

Las columnas decimales almacenan números con un número de dígitos especificado por el usuario. El rango de números que usted puede almacenar es 10-130 a 10124. El tipo de dato decimal puede tomar dos formas, DECIMAL(p) punto flotante y DECIMAL(p,s) punto fijo. El tipo de dato DECIMAL almacena números de punto flotante de hasta 32 dígitos significativos, donde p es el total de dígitos significativos, o la precisión. El formato DECIMAL(p) tiene un rango de valor absoluto entre 10-130 y 10124.

En un número de punto fijo, DECIMAL(p,s) el punto decimal es fijado en un lugar específico, independientemente del valor del número. La precisión es el número total de dígitos significativos que una columna puede almacenar, de 1 a 32. La escala es el número total de dígitos que caen a la derecha del punto decimal. Una columna DECIMAL con una definición (5,2) podría almacenar un número de cinco dígitos con tres dígitos antes del punto decimal y dos dígitos después del punto decimal. Especificar precisión y escala es opcional. Sin precisión DECIMAL es tratado como DECIMAL(16), un decimal con

precisión 16. Sin escala DECIMAL es tratado como un decimal de punto flotante.


Nota: El tipo de dato numérico es un sinónimo para DECIMAL de punto fijo.


La ilustración de arriba muestra las ventajas del uso del tipo de dato DECIMAL sobre el tipo FLOAT ó DOUBLE PRECISION.

DECIMAL permite mayor precisión y la posibilidad de redondear un número. Una columna tipo DECIMAL típicamente almacena números que deben ser almacenados y desplegados exactamente como son introducidos (por ejemplo, tarifas o porcentajes). La precisión disponible de FLOAT puede cambiar de máquina a máquina, lo cual puede causar problemas cuando se transfieren datos a través de una red. Una columna tipo FLOAT típicamente almacena números científicos que deben ser calculados solo aproximadamente.


Las columnas MONEY

almacenan montos monetarios. Los valores monetarios se despliegan anteponiéndoles el signo de dólar ($). Se pueden especificar hasta 32 dígito significativos con el tipo MONEY, al igual que con el tipo DECIMAL. De modo similar a las columnas decimal, las columnas MONEY pueden ser definidas con una precisión y escala dadas. Las columnas MONEY son también tratadas como números decimales fijos. Una columna MONEY se define por defecto como DECIMAL(16,2) si no se especifica precisión o escala. Se requieren nueve bytes para almacenar el valor por defecto. Usted puede ahorrar espacio en disco definiendo solo el máximo tamaño posible para un campo money. El tamaño puede ser incrementado posteriormente si se requiere.


Las columnas SERIAL contienen números que son asignados por el sistema a cada fila de la tablay son almacenados como INTEGER. Cuando una fila es introducida, se le asigna el siguiente número en la secuencia. El valor inicial por defecto es uno y el mayor valor serial que es posible asignar es arriba de 2.1 billones. Una tabla puede contener solo una columna SERIAL y esta columna es usualmente la llave primaria. Si el número inicial (semilla) es 100, a la primera fila que se introduzca se le asignará el valor de 100. No intente cambiar un número serial una vez que este haya sido asignado. No puede ser actualizado con el estatuto UPDATE. Cuando una fila es borrada, los datos son eliminados, pero el valor SERIAL continuará incrementándose. De esta manera, al agregar una nueva fila a esta le será asignado el siguiente número en la secuencia SERIAL. Los números SERIAL no pueden ser reutilizados sin programación especial.

Consejo:

Aún cuando no es imposible cambiar un número serial, se recomienda no hacerlo. Si su programa tiene que mantener un número de identificación seriado con propósitos de auditoría, el cual no deba tener huecos, use un método diferente para generar esos números.


El

tipo de dato fecha (DATE) se usa para almacenar fechas calendario. Aunque las fechas son almacenadas como enteros, los datos fecha pueden ser insertados en una columna DATE usando cualquiera de los formatos de fecha listados arriba. El tipo de dato fecha es el número de días desde el 31 de diciembre de 1899. El 1 de enero de 1900 es el día 1. En formas, reportes y estatutos SELECT, cualquier carácter no-numérico, incluyendo el espacio, puede ser usado para separar la secuencia de mes, día y año, como se muestra en la transparencia. En las formas y los reportes, usted puede decidir los detalles exactos para presentar los valores fecha. Cuando se introducen valores fecha en reportes y estatutos SELECT, los valores deben estar entrecomillados. Ejemplo: WHERE end_date > ‘1/13/1996’ Pueden efectuarse cálculos con datos fecha; por ejemplo:


WHERE last_date = TODAY + 10

Nota:

La variable de ambiente DBDATE puede ser ajustada para cambiar el formato de fecha. El formato por defecto es mdy4/, el cual despliega mm/dd/aaaa.


El tipo de dato DATETIME se usa cuando se desea almacenar valores que representan un punto específico en el tiempo.

Los datos DATETIME permiten mayor precisión que los datos fecha, así como una granularidad seleccionable. La precisión de los datos DATETIME pude variar desde año hacia abajo hasta una fracción de segundo. Ejemplos: DATETIME (1996-4-24 12:00) YEAR TO MINUTE DATETIME (16 12:23) DAY TO MINUTE DATETIME (31:234) SECOND TO FRACTION. Los datos DATETIME pueden contener cualquier punto válido en el tiempo entre el año 1 al 9999 D.C.


La ilustración de arriba lista los rangos de valores para cada campo DATETIME. Estos valores están siempre en orden decreciente de granularidad. Los datos DATETIME pueden contener solamente combinaciones válidas de fecha-hora. Cualquier intento de asignar una combinación inválida causará una condición de error. Por ejemplo, usted no puede definir la vigesimoquinta hora del día, ni el 31 de junio de cualquier año, o el 29 de febrero de un año que no sea bisiesto.


Los datos INTERVAL se usan para almacenar valores que representan períodos. En el diagrama de arriba, el primer INTERVAL puede ser expresado como 94 años y 8 meses. El segundo intervalo podría ser expresado como 560 días, 2 horas y 25 minutos. Ejemplos: INTERVAL (5-3) YEAR TO MONTH INTERVAL (11:15) HOUR TO MINUTE Un dato INTERVAL puede expresar períodos tan grandes como 9,999 años y 11 meses o tan pequeños como una fracción de segundo.


Los tipos de dato INTERVAL no pueden contener meses y días. Esto se debe a que el número de días en un mes varía con el mes; mayo tiene 31 días, mientras que septiembre tiene 30. El número de días en un mes puede variar también con el año; el número de días de febrero cambia de 28 a 29 cada cuatro años, con las excepciones especiales del comienzo de algunos siglos. Debido a estas particularidades en los calendarios, ANSI dividié los tipos INTERVAL en dos subtipos, año-a-mes y día-hora.


Los servidores de bases de datos son capaces de almacenar datos de caracteres de longitud variable dentro de una columna. Las columnas de este tipo son llamadas VARCHAR. Las columnas VARCHAR a menudo reducen el desperdicio de espacio en disco cuando se comparan con los mismos datos almacenados en columnas de tipo CHAR. Las columnas de tipo VARCHAR no están disponibles en algunos servidores. El principal beneficio al usar tipos de dato VARCHAR es que cuando se usan correctamente pueden incrementar el número de filas por página de almacenamiento en disco. En consecuencia, los queries pueden ejecutarse más rápidamente. Las operaciones de inserción y eliminación también pueden ser ligeramente más rápidas. Las columnas VARCHAR pueden almacenar entre 0 y 255 bytes. Cuando se especifica un dato tipo VARCHAR, debe declararse una longitud máxima para la columna. El desarrollador puede especificar opcionalmente una longitud mínima, también por razones de rendimiento. Cuando una fila es actualizada en una tabla con columnas VARCHAR, la cantidad de trabajo que el servidor necesita efectuar depende de la longitud de la nueva fila, comparado con la longitud de la fila antigua. Si la nueva fila es de la misma longitud que la anterior, el tiempo que toma actualizar la fila no será significativamente diferente que si las columnas fueran de longitud fija. Si la nueva fila es mayor que la anterior, el servidor tendrá que ejecutar muchas operaciones extra. De esta manera, actualizar una tabla con columnas VARCHAR puede a veces ser más lento que actualizar una tabla con columnas de longitud fija.


Usted puede mitigar este efecto especificando una longitud mínima que sea del tamaño suficiente para la mayoría de los datos de la columna. De esta forma, la mayoría de las columnas usarán la longitud mínima; solamente se desperdicia un pequeño espacio de relleno y las actualizaciones serán lentas cuando un valor normal sea reemplazado por uno mas largo. El parámetro max-size establece el límite máximo de caracteres permitidos para la columna. El parámetro min-size fija el tamaño mínimo que será reservado siempre para los datos dentro de la columna. Además de los datos contenidos en una columna VARCHAR, se almacena un indicador de longitud al principio de la columna, el cual consume un byte. Nota: El tipo CHARACTER VARYING provee la misma funcionalidad que el tipo VARCHAR y cumple con los estándares ANSI. Los tipos de dato NVARCHAR almacena cualquier cadena de letras, números y símbolos. El tipo de dato NVARCHAR es reconocido solamente cuando está habilitado por medio de la variable de ambiente DBNLS.


Objetos

binarios largos o BLOB’s son cadenas de bytes de valor y longitud arbitrarios. Un BLOB puede contener imágenes digitalizadas o sonido, un módulo objeto relocalizable, o un contrato legal. Un BLOB puede ser cualquier colección arbitraria de bytes para cualquier propósito. Cualquier cosa que usted pueda almacenar en un sistema de archivos de computadora puede ser almacenado en un BLOB. Se permite almacenar BLOB’s como columnas dentro de una base de datos. El límite teórico de un BLOB es sobre 232 bytes. El límite práctico está determinado por la capacidad del disco duro.


Existen

dos tipos de BLOB’s: TEXT y BYTE. TEXT almacena información basada en caracteres: • Documentos de procesadores de texto • Archivos ASCII planos. BYTE almacena información no basada en caracteres: • Imágenes digitalizadas • Sonido digitalizado • Hojas de Cálculo • Cualquier archivo hecho de valores byte arbitrarios Ejemplos de datos BYTE incluyen imágenes de fotografías y documentos. Nota:

La palabra BLOB no aparece en algún menú; es un término genérico para los tipos de datos TEXT y BYTE.


Un objeto de datos

tipo TEXT está restringido a una combinación de texto ASCII (y unos cuantos caracteres de control específicos), tales como: • Archivos de procesadores de palabras • Menúes • Capítulos manuales • Especificaciones de ingeniería • Resúmenes • Contratos legales • Archivos de código de programas fuente • Los caracteres CONTROL-I, CONTROL-J y CONTROL-L Los datos TEXT tienen las siguientes características: • No se almacenan en una columna de una tabla; en vez de eso, se almacenan en un espacio

separado • Están sujetos a disponibilidad de espacio en disco cuando se especifica una variable de

longitud ilimitada • Permiten la capacidad multimedia dentro de una base de datos Nota:

Los datos TEXT no deben ser confundidos con los tipos CHAR o VARCHAR.


Un dato tipo BYTE

puede almacenar cualquier tipo de datos binarios, tales como: • Hojas de cálculo • Módulos de programas • Imágenes digitalizadas; por ejemplo, fotografías o dibujos • Patrones de voz. El tipo de dato BYTE es una colección de bytes. Se conoce solamente la longitud del BLOB y la localidad de almacenamiento en disco. Otros programas pueden ser llamados para desplegar la información BLOB.


cust_numfirst_namelast_nameaddresscitystatezipphonecredit_card_typecredit_card_numcard_exp_date

customer

emp_numfirst_namelast_namesoc_sec_numaddresscitystatezipphonehire_datestore_code

employee

rental_numcust_numemp_numrental_date

rental_master

vid_type_codeeff_dateold_price

price_change

store_codestore_nameaddresscitystatezipmgr_emp_num

store

vid_numdist_stock_numtitlereceived_datedist_codevid_type_codestore_code

video

dist_codedist_name

distributorrental_numvid_numberrental_price

rental_detail

vid_type_codevid_type_descripcurrent_price

video_type

Data Types: Video Rental System*

char(3)char(20)char(80)char(20)char(2)char(10)integer

serialchar(20)char(30)char(80)char(20)char(2)char(10)char(12)char(15)char(20)datechar(2)

datetimemoney(4,2)

char(2)char(20)money(4,2)

serialsmallintchar(50)datechar(3)char(2)char(3)

integerintegermoney((4,2)

char(3)char(20)

serialchar(20)char(30)char(11)char(80)char(20)char(2)char(10)char(12)datechar(3)

serialintegerintegerdate


EJERCICIO DE LABORATORIO 9

Normalización Capítulo 6 – Pág. 115

Capítulo

6

Normalización

Objetivos:

Al final de este módulo, usted será capaz de:

• Definir datos normalizados

• Comprobar los beneficios de la normalización de los datos

• Definir las primeras tres formas normales

• Discutir cuando los datos deben o no ser normalizados


Este módulo cubre la verificación del modelo lógico de datos a través de la normalización.


Normalización es la formalización de las reglas que son aplicables cuando se asocian atributos

con entidades. La normalización es materia de teoría que cubre el análisis y descomposición de

entidades lógicas en un nuevo juego de entidades que exhiban las propiedades físicas más

deseables.

Durante la normalización, se examinarán y resolverán las estructuras del modelo lógico que

pueden convertirse en propiedades indeseables del modelo físico.

El propósito del proceso de normalización es asegurar que el modelo conceptual de la base de

datos trabajará. Un modelo no-normalizado puede implementarse, pero presentará problemas

al desarrollar aplicaciones y manipular los datos. La teoría de la normalización está basada en la

observación de que un cierto juego de relaciones tiene mejores propiedades para insertar,

actualizar y eliminar datos de una base de datos.

Nota:

Existe cierto grado de normalización inherente en sus diagramas de entidad-relación como

resultado de la ejecución de los pasos iniciales al definir y resolver relaciones. Aplicar las

formas normales a su modelo ER es un buen camino para hacer una doble verificación buscando

problemas potenciales.


Un modelo normalizado es más flexible y con más posibilidad de servir a un rango amplio de

aplicaciones de acuerdo a las necesidades del usuario final con mínimos cambios de estructura

conforme se desarrollan nuevas aplicaciones. Será menor la posibilidad de que las nuevas

aplicaciones forcen un cambio en el diseño de la base de datos.

La normalización reduce datos redundantes, hace más fácil el mantener los datos precisos y

consistentes, además de reducir el espacio requerido para almacenar los datos.

El diseño simple y lógico puede resultar en una mejor efectividad y productividad del

programador. La normalización reduce los costos por mantenimiento de una aplicación, dado que

los cambios a la aplicación son hechos fácilmente.


La normalización incluye varios pasos para reducir sucesivamente las entidades para exhibir

las propiedades físicas más deseables. Estos pasos son definidos como reglas de normalización.

Las reglas son nombradas como formas normales.

Existen varias formas normales usadas para organizar datos. Las primeras tres formas, la

primera forma normal (1NF), segunda forma normal (2NF), y tercera formal normal (3NF), son

las más comúnmente usadas y son el objetivo de este módulo.

Cada forma normal constriñe los datos a ser mejor organizados que la última forma. Por esta

razón, cada forma normal debe ser observada antes de aplicar la siguiente forma normal.


Una relación está en primera forma normal si no hay grupos repetidos (domains). Cada entidad

debe tener un número fijo de atributos simples.


El ejemplo de arriba muestra una entidad order la cual no está en primera forma normal. La

entidad contiene atributos repetidos. Item y quantity aparecen de una a cuatro veces en cada

instancia, dependiendo del número de piezas de un pedido en particular.

Una entidad que no está en primera forma normal es menos flexible. En el ejemplo de arriba, el

número máximo de piezas que pueden ser incluídas en cada pedido es de cuatro. Si usted

necesita incluir diez piezas, la entidad order tendría que ser modificada para incorporar el

cambio.


Convierta las entidades a la primera forma normal para quitar grupos repetidos.

Para poner la entidad order en primera forma normal, elimine los grupos repetidos de los

atributos item y q_item, como se muestra arriba. La llave primaria de la entidad order es

ahora una llave compuesta de order_num y item_num.

Ahora el máximo número de piezas en un pedido puede ser incrementado sin modificar la

entidad order.


Una relación está en segunda forma normal si esta en primera forma normal y todos sus

atributos dependen de su llave primaria completa.

Si una relación está en segunda forma normal, la llave primaria completa es necesaria para

identificar todos los atributos asociados. Recuerde, una llave primaria es un mínimo juego de

atributos requerido para identificar de manera única una instancia. Un atributo no-llave, o

descriptor, es cualquier atributo que no forma parte de la llave primaria.

La segunda forma normal requiere que cada atributo no-llave necesite la llave primaria

completa para identificación única. Cada atributo no-llave debe ser completamente

dependiente funcionalmente de la llave primaria.

Nota:

La segunda forma normal es usual solamente cuando se tiene una llave primaria compuesta.


Dependencia funcional indica que hay una liga entre los valores en dos diferentes atributos.

Las dependencias funcionales en la entidad order se muestran arriba. El atributo quantity es

funcionalmente dependiente de order_num y item_num. Esto significa que los valores de

order_num y item_num deben ser conocidos para una instancia dada antes de que el valor de

quantity para esa instancia pueda ser determinado.

El atributo paid_date es funcionalmente dependiente solo del atributo order_num, no de la

llave primaria completa de la entidad. Esto significa que el valor de paid_date puede ser

determinado para una instancia en particular si el valor de order_num es conocido,

independientemente de si el valor de item_num es o no conocido.


En el ejemplo no-normalizado de arriba, order_date, total_amt y paid_date deben ser

suministrados para cada artículo de un pedido. La información es redundante para pedidos que

tienen más de un artículo. Como resultado, cuando se cambie order_date, total_amt o

paid_price para un pedido con varios artículos, debe cambiarse en varios lugares.


Convierta entidades en primera forma normal a segunda forma normal quitando atributos que

no dependan de la llave primaria completa.

Los atributos order_date, total_amt y paid_date en el ejemplo de arriba violan la segunda

forma normal para la entidad order. Estos atributos deben ser puestos en otra entidad para

normalizar la entidad order. Dado que order_date, total_amt y paid_date son todos

dependientes de order_num, hemos creado una entidad order_master con order_num como la

llave primaria. Los atributos order_date, total_amt y paid_date han sido movidos a la entidad

order_master.

Ahora si order_date, total_amt o paid_date son cambiados en un pedido, solamente han de ser

modificados en un lugar, independientemente de cuantos artículos tiene el pedido.

Nota:

Dado que la entidad order ahora contiene solo información detallada acerca de cada pedido, la

hemos renombrado como order_detail.


La tercera forma normal requiere que cada atributo no-llave en segunda forma normal dependa

de la llave primaria completa y solamente de la llave primaria. Esto elimina la dependencia

transitiva en la cual los atributos no-llave dependen no solamente de la llave primaria completa,

sino también de otros atributos no-llave que a su vez dependen de la llave primaria completa.


Una entidad en segunda forma normal puede tener atributos que son dependientes de

atributos no-llave dentro de la entidad. Los atributos que dependen de un atributo no-llave en

la entidad son considerados como transitivamente dependientes de la llave primaria de la tabla.

La entidad order_price mostrada arriba no está en tercera forma normal porque es

transitivamente dependiente de la llave primaria de la entidad.


En el ejemplo no-normalizado de arriba, el unit_price para un artículo debe ser suministrado

para cada pedido. Dado que unit_price es transitivamente dependiente de la llave primaria,

ocurren algunos problemas que se describen en la transparencia de arriba.


El atributo unit_price es transitivamente dependiente de la llave primaria, por lo que debe ser

movido a otra entidad, para que la entidad order_price esté en tercera forma normal. Dado

que unit_price depende de stock_num y mfr_code, stock_num y mfr_code son copiados de la

entidad order_price para formar la llave primaria en la entidad stock creada para unit_price.

Como resultado de este cambio:

• El unit_price puede ser introducido para un artículo aún pensando que no haya pedidos

conteniendo el artículo

• El unit_price no se pierde si todos los pedidos que contienen un determinado artículo son

eliminados

• El unit_price solamente ha de ser cambiado en un lugar si cambia el precio unitario para un

determinado artículo.

• No hay datos redundantes y se ahorra espacio en disco, dado que unit_price existe

solamente una vez por artículo.

Nota:

Si usted necesita registrar cual precio unitario ha sido cargado a cada pedido, una columna

unit_price_charged debe existir en la tabla order, dado que la columna unit_price en la tabla

stock es más probable que cambie con el tiempo.


Para convertir a 1NF, elimine todos los grupos repetidos.

Para convertir a 2NF, elimine los atributos que no son dependientes de la llave primaria

completa.

Para convertir a 3NF, elimine los atributos que dependan de otros atributos no-llave.

Consejo:

El siguiente dicho podría ayudar a recordar las tres primeras formas normales:

La llave, la llave completa y solamente la llave


Cuando normalice su base de datos, no divida entidades completamente normalizadas en

entidades más pequeñas. Usted puede descomponer cada entidad en un juego de entidades que

consistan de solamente la llave primaria y un atributo no-llave.

Esto no violará las reglas de normalización. Dividir entidades normalizadas agregan complejidad

innecesaria al modelo de datos y al proceso de desarrollo de aplicaciones.

Base su modelo inicial en los conceptos del negocio y entonces aplique la teoría de

normalización para verificar la validez estructural de las entidades.

El proceso de normalización está basado solamente en el significado de los datos y no

consideran los requerimientos de proceso. Una base de datos completamente normalizada

puede no ser un diseño de base de datos óptimo o cumplir objetivos de rendimiento. Por

ejemplo, usted podría introducir redundancias controladas para asegurar mejor rendimiento;

podría revisar el modelo y cambiarlo a favor de necesidades de procesamiento particulares.

Consejo:

Si usted decide “desnormalizar” el modelo de datos por razones de rendimiento, asegúrese de

documentar su decisión y las razones que están detrás de ella.


Normalice la entidad video en el sistema de renta de videos usando el ERD descrito en la

siguiente página. El problema con el diseño actual es que conducirá a datos redundantes,

complicando el cambio de los datos.

Para cada video, se almacena el título, el número de stock del distribuidor, el distribuidor y el

tipo de video, aún cuando la información es la misma para todas las copias de un título en

particular. Solo el número de video, la fecha de recepción y la tienda podrían ser diferentes

para cada copia.

Los datos redundantes dificultan el mantenimiento. Por ejemplo, cuando cambie el número de

stock del distribuidor para un determinado título, el número de stock del distribuidor debe ser

cambiado para cada copia. Si cambia el tipo de video (después de pocas semanas, una novedad

cambia a regular), el tipo de video debe ser cambiado para cada copia.



customer


employee


rental_master


price_change


store

tape_numtitle_numreceived_datestore_code

dist_codedist_name

distributor

rental_numtape_numrental_price

rental_detail


video_type

Class Exercise: Normalization

Primary keys are in bold . Foreign keys are in italics.

title_numdist_stock_numtitledist_codevid_type_code

video_title

video_tape


732KalenLee123 Circle DrivePalo AltoCA96420415-762-4829VISA46372920998488501/01/97

customer

6JenniferWatson555-39-8472121 Lytton AvePalo AltoCA94304415-328-946111/01/94HLS

employee

3761732612/15/95

rental_master

NR12/01/95$3.25

price_change

HLSHighlands24 Bay AvePalo AltoCA964203

store

98737511/25/95HLS

RCARCA Artists, Inc.

distributor

3761987$3.50

rental_detail

NRnew release$3.50

video_type

Entity Instance: Video Rental System

This page shows a sample entity instance for the normalized video rental system.

37512581Toy StoryRCANR

video_title

video_type


EJERCICIOS DE LABORATORIO 10.

Estatutos SQL para crear una base de datos Capítulo 7 – Pág 139

Capítulo

7 Estatutos SQL para crear una Base de Datos

Objetivos:


• Entender como el modelo lógico de base de datos corresponde al modelo de base de datos

físico

• Escribir un estatuto CREATE DATABASE para crear una base de datos

• Escribir un estatuto CREATE TABLE para crear una tabla de una base de datos

• Escribir un estatuto ALTER TABLE para modificar una tabla de base de datos


Los módulos restantes de este curso cubren el paso final en el diseño de bases de datos

relacionales descrito arriba.


La figura muestra cómo el modelo lógico usado en el diseño de base de datos relacional se

traduce en un esquema físico de base de datos.

El lenguaje de consulta estructurado (SQL) es el lenguaje usado para traducir un modelo lógico

de base de datos en un esquema de base de datos. Un esquema es la definición física de las

tablas en una base de datos. Una tabla es una representación de dos dimensiones de columnas y

filas.

SQL fue originalmente desarrollado por IBM como un lenguaje de consulta a la medida. Hoy

día, se ha convertido como el lenguaje estándar de la industria y herramienta de comunicación

con bases de datos relacionales.


Una base de datos se crea con el estatuto CREATE DATABASE. El estatuto mostrado arriba

podría crear una base de datos llamada videos.

Existen extensiones del estatuto CREATE DATABASE que soportan funcionalidades

adicionales provistas por el servidor de base de datos. El administrador de la base de datos

necesita tomar varias decisiones antes de crear una base de datos, tales como donde la base

de datos será creada. Las decisiones variarán dependiendo del servidor de base de datos que

se esté usando.


Una tabla se crea con el estatuto CREATE TABLE.

El estatuto CREATE TABLE mostrado arriba crea una tabla llamada video_type con dos

columnas. El estatuto especifica el tipo de dato para cada columna.

Hay muchas extensiones al estatuto CREATE TABLE que soportan funcionalidad adicional

provista por el servidor de la base de datos. Algunas de estas extensiones son discutidas en el

módulo Data Integrity.


Una vez que una tabla ha sido creada, usted puede modificarla usando el comando ALTER

TABLE.

El ejemplo de ALTER TABLE mostrado arriba agrega una columna llamada curen_price a la

tabla video_type.

Existen muchas variantes del estatuto ALTER TABLE. Algunas de estas variantes son

discutidas en el módulo Data Integrity.


Ejercicios de Clase: Evalua las expresiones SQL del Sistema de Renta de Video

Evaluar las siguientes expresiones SQL y contestar las siguientes preguntas:

• ¿Corren exitosamente estas expresiones de SQL?

- Si es asi, ¿Qué es lo que hacen? ¿Es esto lo que deben hacer?

- Si no, ¿Cuál es el problema? ¿Cómo lo arreglarías?

• ¿Hay otra mejora que puedas hacer?

(Sugerencias: Recuerda los lineamientos para nombrar descritos en el módulo

Especificaciones de Atributos.)

Discute las respuestas en grupo.

create database videos; create table store ( store code char(20), store_name char(20), address char (80), city char(20), state char(20), zip char(10)); create table video_title title_num serial, dist_stock_num serial, title char(50), dist_code char(2), div_type_code char(2)); alter table store ( add_phone char(12)); create table video_tape ( tape_number integer, title_num integer, received_date date, store_code char(3));


Soluciones

Una solución simple para el ejercicio se muestra en las siguientes lineas. Los cambios hechos a

las expresiones en la página previa estan resaltados en negritas.* create database videos; create table store ( store_code char(3), store_name char(20), address char(80),

city char (20), state char(2), zip char(10), mgr_emp_num integer );

create table video_title ( title_num serial, dist_stock_num integer , title char(50), dist_code char(3), vid_type_code char(2)); alter table store add phone char(12); create table video_tape ( tape_num serial , title_num integer, received_date date, store_code char(3)); *También puede ser apropiado usar el tipo de dato VARCHAR para algunas columnas de

caracteres.

Integridad de los datos Capítulo 8 – Pág. 149

Capítulo

8

Integridad de los datos

Objetivos:


• Entender los conceptos básicos de integridad de datos

• Explicar los diferentes tipos de constraints de integridad de datos

• Implementar constraints de integridad de datos


Data Integrity es la precisión o calidad de los datos en una base de datos.

La Integridad Referencial es usada par asegurar las relaciones entre tablas.

La integridad de las entidades es asegurada creando una llave primaria que identifique de

manera única a cada fila en la tabla.

La integridad semántica es asegurada usando las siguientes constraints:

Data types El tipo de datos define los tipos de valores que usted puede

almacenar en la columna.

Default Values El valor por defecto es el valor insertado en una columna cuando

no se especifique un valor explícito.

Check constraints Un check constraints especifica condiciones sobre los datos

insertados o actualizados en una columna.


Un

referential constraint permite al usuario especificar las llaves primarias y foráneas para

asegurar las relaciones padre-hijo (maestro-detalle). Para definir una constraint referencial,

un usuario debe tener el privilegio REFERENCES o ser el dueño de la tabla. Las constraints

referenciales permiten establecer las restricciones descritas abajo en actualizaciones,

inserciones o eliminaciones.

Por ahora, asuma que la verificación de constraint referencial es hecha conforme cada fila es

insertada, actualizada o norrada.

He aquí algunas reglas que aseguran constraints referenciales:

• Si un usuario borra una llave primaria y existen llaves foráneas, el borrado falla.

• Si un usuario actualiza una llave primaria, y existen valores de llaves foráneas que no

corresponden al valor de la nueva llave primaria, la actualización falla.

• No hay restricciones asociadas con el borrado de llaves foráneas.

• Si un usuario actualiza una llave foránea y no hay llave primaria correspondiente al nuevo

valor, no-nulo de llaves foráneas, la actualización falla.

• Todos los valores dentro de una llave primaria deben ser unique. Un intento de insertar o

duplicar el valor dentro de la llave, fallará.

• Cuando un usuario inserta una fila en una tabla hija, si todas las llaves foráneas son no-null

y no hay la correspondiente llave primaria, la inserción falla.


Arriba se listan tres de los tipos de constraints referenciales. Estas se describen en las

próximas páginas.


Una constraint ciclica asegura una relación padre-hijo (maestro-detalle) entre tablas. Esta

constraint asegura que cada fila de la tabla hija tenga su correspondiente fila en la tabla

padre.


Un ejemplo de constraint referencial cíclica se muestra en esta lámina.

Para asegurar una constraint cíclica referencial, usted debe especificar una llave primaria en la

tabla padre y su correspondiente llave foránea en la tabla hija. Solamente puede haber una

llave primaria por tabla. La cláusula REFERENCES especifica la tabla padre. Dado que solo se

permite una llave primaria en la llave padre, no es necesario incluir la columna de llave primaria

en la cláusula.

El ejemplo de arriba asegura la relación padre-hijo entre las tablas rental_master y

rental_detail. La columna rental_num está designada como la llave primaria en la tabla

rental_master, lo cual significa que solamente valores únicos pueden ser agregados a la

columna. La columna rental_num en la tabla rental_detail está designada como la llave foránea

referenciando la columna rental_num en la tabla rental_master. Esto asegura que registros de

detalle de renta serán agregados solamente si un rental master existe y un rental master no

puede ser borrado si existen rental details asociados.


Las constraints referenciados-a-si-mismos aseguran las relaciones padre-hijo dentro de una

tabla. Ellas aseguran que cada fila hijo en la tabla tenga una fila padre correspondiente en la

tabla.


Un ejemplo de constraints referencia-a-si-mismo se muestra arriba.

En este ejemplo, la tabla employee es usada para registrar a todos los empleados y gerentes a

los cuales ellos están asignados. Una constraint referencia-a-si-mismo se usa para asegurar

que el gerente asignado a cada empleado exista en la tabla employee. En otras palabras, un

empleado no puede tener un gerente que no sea empleado.

La columna emp_num es la llave primaria para la tabla employee, y la columna mgr_emp_num es

una llave foránea referenciando a emp_num. Esto significa que los valores de mgr_emp_num

deben existir en la columna emp_num antes de poder agregar la fila a la tabla.


Las constraints multiple path se refieren a una llave primaria que puede tener varias llaves

foráneas correspondientes.


El ejemplo de arriba muestra una tabla padre, store, que tiene dos diferentes hijos, las tablas

video_tape y employee.


Usted puede agregar constraints a una tabla después de haber sido creada usando el estatuto

ALTER TABLE. El dibujo de arriba provee ejemplos de cómo constraints de llaves primarias y

secundarias pueden ser agregadas a la tabla después de heber sido creada.

Existen muchas variaciones del estatuto ALTER TABLE.


Las constraints unique aseguran que cualquier fila insertada o actualizada en una tabla tenga un

valor único en la(s) columna(s) especificada(s). En el ejemplo de arriba, una constraint unique

ha sido puesta en la columna phone. Esto asegurará que cada número telefónico agregado a la

tabla employee sea único.

Nota:

Una columna agregada con constraint de llave primaria garantiza que sea única y no puede

tener una constraint unique.


Si usted está agregando una fila de datos a una tabla y no especifica un valor explícito para

una columna, el valor por defecto para esa columna es insertado. Como se muestra en el

ejemplo de arriba, se puede definir valores por defecto para columnas como parte del estatuto

CREATE TABLE. Si un valor por defecto no es especificado para un columna, el defaul es null.

Usted puede especificar valores literales como defaults similares al mostrado en el primer

ejemplo de arriba. San Francisco es el valor por defecto para la columna city. El valor literal

que usted suministre debe coincidir con el tipo de datos de la columna. Por ejemplo, literales

enteras pueden ser especificadas para columnas INTEGER, SMALLINT, DECIMAL, MONEY,

FLOAT y SMALLFLOAT.

Usted puede especificar también ciertas funciones como valores por defecto. En el segundo

ejemplo de arriba, la función TODAY es especificada como el valor por defecto para la columna

rental_date. Esto significa que la fecha del día será insertada si no se provee una fecha

alternativa. Para mayor información sobre las funciones que pueden ser especificadas como

valores por defecto, refiérase a Guide to SQL.


Si usted no indica un valor por defecto para una columna, el default es null a menos que usted

incluya la palabra llave NOT NULL en la definición de la columna. En este caso, no existirá valor

por defecto para la columna y usted debe introducir un valor dentro de la columna cuando

usted agregue una fila a la tabla o actualice una fila de la tabla. Si usted no especifica un valor

para esa columna, el insert o update falla.

En el ejemplo de arriba, no se permiten valores nulos en ninguna columna de la tabla

rental_master. La única columna con un valor por defecto es la columna rental_date.

Consejo:

Usted debe especificar siempre NOT NULL para columnas que son parte de una llave primaria.


Una check constraint especifica condiciones sobre los datos insertados en una columna. Cada

fila insertada dentro de la tabla debe cumplir las condiciones especificadas.

EN el ejemplo mostrado arriba, la tabla customer tiene una check constraint en la columna

card_exp_date, la cual especifica que la fecha introducida en card_exp_date debe ser mayor

al 1 de Enero de 1996.

Existen muchas formas de implementar check constraints en las tablas de sus bases de datos.

Refiérase a Guide to SQL para mayor información.

Ejercicios de Clase: Evalua las expresiones SQL del Sistema de Renta de Video


Evaluar las siguientes expresiones SQL y contestar las siguientes preguntas:

• ¿Corren exitosamente estas expresiones de SQL?

- Si es asi, ¿Qué es lo que hacen? ¿Es esto lo que deben hacer?

- Si no, ¿Cuál es el problema? ¿Cómo lo arreglarías?

- ¿Hay otra mejora que puedas hacer?

• Discuta las respuestas en grupo.

create database videos; create table store ( store_code char(3) not null, store_name char(20) not null, address char(80),

city char (20), state char(2), zip char(10), mgr_emp_num integer, primary key store_code),

create table employee ( emp_num serial, first_name char(3), last_name char(30) not null, soc_sec_num char(11) not null, address char(80), city char(20), state char(2) default CA, zip char(10), phone char(12), hire_date date, default today, store_code char(3), not null, primary key (emp_num), foreign key (store_code) unique (soc_sec_num));


Soluciones


Una solución simple para el ejercicio se muestra en las siguientes lineas. Los cambios hechos a

las expresiones en la página previa estan resaltados en negritas.

create database videos; create table store ( store_code char(3) not null, store_name char(20) not null, address char(80),

city char (20), state char(2), zip char(10), mgr_emp_num integer, primary key (store_code)),

create table employee ( emp_num serial not null , first_name char(20), last_name char(30) not null, soc_sec_num char(11) not null, address char(80), city char(20), state char(2) default 'CA', zip char(10), phone char(12), hire_date date default today, store_code char(3), not null, primary key (emp_num), foreign key (store_code) references store, unique (soc_sec_num));

Insertando y seleccionando datos Capítulo 10 – Pág. 181

Capí tu lo

10 Insertando y seleccionando datos

Objetivos

Al final de este módulo, usted será capaz de: • Agregar datos a una base de datos usando el estatuto INSERT • Recuperar información desde una base de datos usando el estatuto SELECT


Una vez que se ha creado una base de datos, se le puede agregar información usando el estatuto INSERT El primer INSERT mostrado arriba agrega una fila a la tabla video_type con los siguientes valores: vid_type_code CH vid_type_descrip Childrens current_proce $1.00 Se puede usar este formato del estatuto INSERT, especificando un valor para cada columna en la tabla en el orden de las columnas que fue establecido cuando la tabla fue creada o alterada. El segundo INSERT de arriba agrega una fila a la tabla store con los siguientes valores: store_code HLS store_name Highlands address null city null state null zip null mgr_emp_num 5


En este formato del estatuto INSERT, se especifican tanto las columnas como los valores. Los valores deben aparecer en el mismo orden que las columnas, y el número de valores listado debe ser el mismo que el número de columnas listadas. Use este formato cuando no desee introducir un valor para cada columna en la tabla. Cuando no se especifica un valor para una columna, el valor por defecto, si lo hay, es insertado. Si se tiene una columna SERIAL en la tabla, y se desea insertar una fila con el siguiente número consecutivo serial, especifique un cero como valor para la columna serial en la instrucción INSERT. Nota: Existen mejoras del estatuto INSERT que permiten funcionalidades adicionales. El curso Structured Query Language cubre muchas de esas extensiones.

Precaución!

Si se intenta insertar información que no cumpla con los criterios asociados a las constraints de la tabla, los datos no serán insertados y el servidor de base de datos regresará un error.


Se pueden recuperar datos desde una base de datos usando el estatuto SELECT. El estatuto SELECT mostrado arriba regresa todos los valores de las columnas en todas las filas de la tabla video_type. El asterisco (*) indica que todas las columnas en la tabla serán recuperadas.


Este estatuto SELECT regresa solo los valores en las columnas title y vid_type_code de todas las filas de la tabla video_title. Se puede especificar que se desea recuperar los valores en cualquier columna o todas las columnas de una tabla listando las columnas que se desean ver.


Los dos ejemplos previos de SELECT mostraron como recuperar datos de una sola tabla. Uno de las más poderosas capacidades de una base de datos relacional es que usted puede recuperar datos de varias tablas. El ejemplo de SELECT de arriba muestra como recuperar datos de dos tablas. En este ejemplo, las columnas title y su correspondiente vid_type_descrip son seleccionadas desde las tablas video_title y video_type. Para poder recuperar datos correctamente desde múltiples tablas, es necesario unir (join) las tablas ligando los valores de las llaves primarias de la tabla padre a sus correspondientes valores de llaves foráneas en la tabla hija. La unión de tablas se hace mediante la cláusula WHERE del estatuto SELECT, quien especifica cuales columnas necesitan ser ligadas. Si las columnas de llaves foráneas y sus correspondientes llaves primarias tienen el mismo nombre, como aquí mismo recomendamos, es necesario anteponer al nombre de cada columna el nombre de su tabla y un punto (ejemplo: tabla1.column1) para poder eliminar la ambigüedad. Nota: Existen numerosas mejoras del estatuto SELECT que proveen funcionalidad adicional más allá de lo cubierto en este módulo. El curso Structured Query Language cubre muchas de esas extensiones.


Si usted no une las tablas correctamente cuando selecciona datos de varias tablas, resulta un producto cartesiano. Un producto cartesiano consiste de cada posible combinación de filas desde las tablas. El ejemplo de SELECT mostrado arriba solicita datos desde dos tablas y crea un producto cartesiano.

Grupo de laboratorio de diseño de bases de datos Capítulo 11 – Pág.191

Capí tu lo

11 Grupo de Laboratorio de diseño de Bases de datos Relacionales


Trabajen juntos en pequeños grupos como designe su instructor en el ejercicio de laboratorio

descrito arriba. Seleccionen un líder de grupo que modere las discusiones y un miembro del

grupo para documentar el ERD final.

Como grupo, analicen y discutan el texto de la entrevista, consideren alternativas de diseño y

construyan un ERD normalizado.

Elijan a una persona que presente y explique el ERD del grupo como parte de una discusión de

la clase.


• Obtener conocimiento del negocio

• Identificar entidades, atributos y relaciones.

� Determinar conectividad

� Determinar las constraints de cardinalidad

� Determinar existencias dependientes

• Diagramar los objetos de datos usando el método de entidad-relación

• Resolver el modelo lógico de datos (1:1, M:N, redundantes)

• Determinar especificaciones de atributos y tipos de datos

� Identificar llaves primarias y foráneas

� Nombrar atributos

� Determinar requerimientos de no nulos

� Determinar requerimientos unique

• Verificar el modelo lógico de datos a través de la normalización


“Necesitamos diseñar un sistema para registrar problemas de usuarios. Los usuarios de

computadoras dentro de la compañía llaman al teléfono del MIS cuando tienen un problema.

Usualmente es un problema de hardware pero a veces puede estar relacionado con el software

o la red. Pero tu sabes, a veces es simplemente un problema relacionado con el usuario y no es

realmente un problema del MIS. Necesitamos registrar nombre, extensión telefónica y

dirección de correo electrónico de la persona que reporta el problema. Cuando resolvemos el

problema, le llamamos de nuevo al usuario o le mandamos un correo electrónico. Necesitamos

registrar la fecha y hora de la llamada y el tipo de problema; tu sabes, hardware, software ó

red. También necesitamos tener una descripción del problema.

¿Qué pasa enseguida? Cuando el problema es registrado, se le asigna a un ingeniero dentro del

departamento de MIS. El ingeniero corrige el problema y registra la fecha, hora y resolución.

Seguro, un ingeniero está trabajando en muchos problemas al mismo tiempo. Usualmente su

carga de casos es muy pesada. Si ellos no pueden resolver el problema, este es escalado al

ingeniero de siguiente nivel.

Existen tres niveles de ingenieros. Las llamadas son colocadas inicialmente con los ingenieros

de nivel uno y escalan al nivel dos o tres si es necesario. El ingeniero usa su criterio para

escalar un problema al siguiente nivel. ¿Puede un ingeniero ser de diferentes niveles? Oh no;

ellos están ya sea en nivel uno, dos o tres.


Si un usuario llama mas de una vez acerca del mismo problema, necesitamos registrar cada

llamada.

Todo lo que necesito saber acerca de un ingeniero es su nombre, nivel y cuánto tiempo ha

trabajado en el problema individualmente.


Soluciones

problem_numproblem_cdproblem_textresolve_dateresolve_text

problem_numengineer_numassigned_datelength

engineer_numfirst_namelast_namelevel

email_addressfirst_namelast_nameextn

call_numproblem_numemail_addresscall_date

problem_cdproblem_descrip

engineer

case

usercall

problem

problem_type

Problem Tracking SystemSample Solution


En resumen, las bases de datos relacionales ofrecen muchas ventajas sobre los sistemas de

archivos convencionales y las bases de datos jerárquicas y de red. La aproximación entidad-

relación es una metodología que puede ser usada para diseñar una base de datos relacional. La

ilustración de arriba enlista los pasos para el diseño de una base de datos que fueron cubiertos

en este curso.


Los libros de arriba fueron consultados durante la creación de estos materiales de

entrenamiento y son recomendados para posterior lectura sobre los temas de diseño de bases

de datos relacionales.

tipos de datos - eduarmandov.files.wordpress.com€¦ · tipos de datos capítulo 5 – pág. 93...

Documents