Procesamiento de base de datos: Fundamentos, Deseño e Implementación Capítulo 4 Diseño de base de datos Utilizando de normalización 4-1
Objetivos Diseñar bases de datos actualizables para almacenar datos recibidos de otra fuente Utilizar SQL para acceder la estructura de las tablas. Entender las ventajas y desventajas de la normalización. Entender la denormalización. Diseñar una bases de datos de sólo lectura para almacenar datos de bases de datos actualizables. 4-2
Objetivos Reconocer y ser capaz de corregir los problemas de diseño comunes: El problema de multivalor, varias columnas El problema de valores inconsistentes El problema de los valores que faltan El problema de columna de observaciones de propósito general 4-3
Premisas del capítulo Hemos recibido una o más tablas de datos existentes. Los datos son almacenados en una base de datos nueva. PREGUNTA: Los datos serán almacenados como recibido, o deben transformarse para? 4-4
Cuántas tablas hay? Se deben almacenar estas dos tablas como son, o debemos combinarlas en una tabla nueva en la base de datos? 4-5
Evaluar la estructura de tabla 4-6
Conteo de filas de una tabla Para contar el número de filas de una tabla utilice la función incorporada de COUNT(*) en SQL: SELECT FROM COUNT(*) AS NumRows SKU_DATA; 4-7
Examen de las columnas Para determinar el número y tipo de columnas en una tabla, utilice la instrucción SELECT de SQL Para limitar el número de filas recuperadas, utilice el SQL TOP {NumberOfRows} palabra clave: SELECT TOP (10) * FROM SKU_DATA; 4-8
Comprobación de la validez de las supuestas restricciones de integridad referencial Dadas dos tablas con un supuesta restricción de clave foránea: SKU_DATA BUYER (SKU, SKU_Description, Department, Buyer) (BuyerName, Department) Where SKU_DATA.Buyer must exist in BUYER.BuyerName 4-9
Comprobación de la validez de las supuestas restricciones de integridad referencial Para encontrar los valores de claves extranjeros que violan la restricción de los foreign key : SELECT FROM WHERE Buyer SKU_DATA Buyer NOT IN (SELECT Buyer FROM SKU_DATA, BUYER WHERESKU_DATA.BUYER = BUYER.BuyerName); 4-10
Tipo de base de datos Base de datos actualizable, o base de datos de sólo lectura? Si se puede actualizar la base de datos, normalmente queremos tablas en BCNF. Si la base de datos es de sólo lectura, no se podrán utilizar las tablas de la BCNF 4-11
Diseño de bases de datos de actualizable 4-12
Normalización: ventajas y desventajas 4-13
Tabla no normalizada: EQUIPMENT_REPAIR 4-14
Tablas normalizadas: ITEM and REPAIR 4-15
Copia de datos a tablas de nuevas Para copiar datos de una tabla a otra, utilice el comando INSERT INTO TableName de SQL: INSERT INTO ITEM SELECT FROM INSERT INTO REPAIR SELECT FROM DISTINCT ItemNumber, Type, AcquisitionCost EQUIPMENT_REPAIR; ItemNumber, RepairNumber, RepairDate, RepairAmmount EQUIPMENT_REPAIR; 4-16
Elección de no uso de BCNF BCNF se utiliza para controlar las anomalías de dependencias funcionales. Hay veces cuando la BCNF no es deseable. El ejemplo clásico son códigos postales: Los códigos postales casi nunca cambian. Cualquier anomalía tiene probabilidad de ser capturada por las prácticas comerciales normales. No tener que utilizar SQL para unir datos de dos tablas aumentará la velocidad de procesamiento de la aplicación. 4-17
Dependencias multivalor La anomalías de las dependencias multivalor son muy problemáticas. Coloque siempre las columnas de una dependencia multivalor en una tabla separada (4NF). 4-18
Diseño de bases de datos de sólo lectura 4-19
Bases de datos de sólo lectura Read-only databases son bases de datos nooperacionales utilizadas para extraer datos de bases de datos operacionales. Se utilizan para realizar consultas, informes y aplicaciones de minería de datos. Nunca se actualizan (en el sentido de la base de datos operativa pueden tener nuevos datos importados de vez en cuando). 4-20
Denormalización Para bases de datos de sólo lectura, la normalización rara vez es una ventaja. Application processing speed is more important. Denormalización es la unión de los datos de tablas normalizados antes de almacenar los datos. La data es almacena en una tabla nonormalizada. 4-21
Tablas normalizadas 4-22
Denormalizados de los datos Denormalizing the Data INSERT INTO PAYMENT_DATA SELECT FROM WHERE AND STUDENT.SID, Name, CLUB.Club, Cost, AmtPaid STUDENT, PAYMENT, CLUB STUDENT.SID = PAYMENT.SID PAYMENT.Club = CLUB.Club; 4-23
Tablas personalizadas Las bases de datos de sólo lectura a menudo están diseñadas con muchas copias de los mismos datos, pero con cada copia personalizada para una aplicación específica. Considere la tabla PRODUCT: 4-24
Tablas personalizadas PRODUCT_PURCHASING (SKU, SKU_Description, VendorNumber, VendorName, VendorContact_1, VendorContact_2, VendorStreet, VendorCity, VendorState, VendorZip) PRODUCT_USAGE (SKU, SKU_Description, QuantitySoldPastYear, QuantitySoldPastQuarter, QuantitySoldPastMonth) PRODUCT_WEB (SKU, DetailPicture, ThumbnailPicture, MarketingShortDescription, MarketingLongDescription, PartColor) PRODUCT_INVENTORY (SKU, PartNumber, SKU_Description, UnitsCode, BinNumber, ProductionKeyCode) 4-25
Problemas comunes de diseño 4-26
El multivalor, problema de varias columnas El multivalor multivalue, multicolumn problem se produce cuando varios valores de un atributo se almacenan en más de una columna: EMPLOYEE (EmpNumber, Name, Email, Auto1_LicenseNumber, Auto2_LicenseNumber, Auto3_LicenseNumber) Esta es otra forma de una dependencia de multivalor. Solution = como la solución de 4NF para dependencias multivalor, utilice una tabla independiente para almacenar los valores múltiples. 4-27
Valores inconsistentes Inconsistent values se producen cuando usuarios diferentes, o diferentes fuentes de datos, utilizan formas ligeramente diferentes del mismo valor de datos: Codificaciones diferentes: SKU_Description = 'Corn, Large Can' SKU_Description = 'Can, Corn, Large' SKU_Description = 'Large Can Corn Diferente ortografía: Coffee, Cofee, Coffeee 4-28
Valores inconsistentes Particularmente problemáticos son los valores de las claves primarias y foráneas. Para detectar: Utilice la comprobación de la integridad referencial ya discutido para comprobar las claves. Utilizar la cláusula SQL GROUP BY en columnas sospechosas. SELECT FROM GROUP BY SKU_Description, COUNT(*) AS NameCount SKU_DATA SKU_Description; 4-29
Valores que faltan Missing Values Un missing value o null value es un valor que nunca se ha proporcionado. 4-30
Valores nulos Loa valores nulos son ambiguos: Puede indicar que un valor es inadecuado;; DateOfLastChildbirth no es apropiado para un hombre.. Puede indicar que un valor es apropiado pero desconocido; DateOfLastChildbirth es apropiado para una mujer, pero puede ser desconocido. Puede indicar que un valor es apropiado y conocida, pero que nunca se ha introducido; DateOfLastChildbirth es apropiado para una mujer y pueden ser conocidas, pero nadie lo ha grabado en la base de datos. 4-31
Comprobación de valores nulos Use la palabra clave SQL IS NULL para comprobar los valores nulos: SELECT FROM WHERE COUNT(*) AS QuantityNullCount ORDER_ITEM Quantity IS NULL; 4-32
La columna de observaciones de propósito general Una columna de observaciones de propósito general general-purpose remarks column es una columna con un nombre como: Observaciones Remarks Comentarios Comments Notas Notes A menudo contiene datos importantes almacenados en una forma incoherente, verbal y detallada. Un uso típico es almacenar datos de los intereses del cliente. Esta columna puede: Be used inconsistently Contener varios elementos de datos. 4-33