Embedded Files
Alguna vez lo hemos nombrado: el esquema de la base de datos. Pero, ¿qué es? A bote pronto, una representación en un modelo de datos concreto de un sistema de información. Hemos hablado acerca de la gente como ejemplo a esquematizar. Vayamos ahora al Pizza Hut. Bueno al "Pissa Ja", no lo vamos a hacer tan complicado.
En efecto, tenemos una pizzería que sirve a domicilio. Así, sin pensar mucho, tenemos artículos a la venta —pizzas— y clientes que los compran. Supongamos que son tan buenas, las pizzas, que el negocio les va muy bien. Si pensamos un poco más, de los artículos nos interesa un código interno que los identifique, una denominación y un precio de venta al público. Si de los clientes hablamos, teléfono que nos sirve de identificador, un nombre, apellidos y dirección. Asumimos que nuestros clientes viven en las cercanías así que ciudad y provincia no son necesarios. Un cliente puede comprar varias pizzas en una llamada telefónica, incluso del mismo tipo.
Ya hemos pensado. Ya hemos esquematizado, modelado nuestro sistema de información. Solo nos falta trasladarlo a un modelo de datos comprensible por nuestro gestor de base de datos.
Hemos adelantado ya que el nuestro será el modelo relacional, el de las tablas. O sea, que tenemos que construir tablas en base a definir las columnas que las componen y las restricciones que sufren. Para cliente elegimos teléfono, apellidos, nombre y dirección. Para pizza, cod —un código—, nombre de la pizza, descripción y precio de venta al público.
CLIENTE (
tlfno char(9),
apellidos varchar(125),
nombre varchar(60),
dirección varchar(300),
CP (tlfno)
)
PIZZA (
cod smallint,
nombre varchar(60),
descripcion varchar(250)
pvp decimal (4,2)
CP (cod)
)
Por "CP" entendemos clave primaria, una restricción de identificación, la o las columnas que imposibilitan que haya dos filas iguales en una tabla. Para cliente hemos elegido el teléfono y para pizza el código. No es necesario que te contemos aquí el porqué, pero para representar que un cliente compra pizzas necesitamos una tercera tabla. Esta tabla nos dirá quién compra qué, en qué cantidad y qué precio se le cobró.
COMPRA (
cliente char(9),
pizza smallint,
cantidad tinyint,
pagado decimal(4,2),
CP (cliente, pizza)
CAj (cliente) → CLIENTE,
CAj (pizza) → PIZZA
)
Hemos introducido una restricción adicional que aún no te vamos a explicar. Por ahora te vale que "CAj" quiere decir clave ajena.
Esto es un esquema relacional, no del todo formal, no sigue una sintaxis estricta, pero tiene todo lo necesario: nombres de tabla, de columna, tipos de datos y restricciones como la clave primaria. Lo que queremos es conseguir tener datos que más o menos lucen así.
Ya te contaremos cómo sacar provecho de todo esto más adelante.
Hay dos aspectos importantes acerca del esquema como herramienta. Por un lado, el gestor de bases de datos debe saber cómo y de qué manera almacenar los datos. Por otro, el esquema hace lo mismo para nosotros mismos. Dicho de otra forma, necesitamos tener a mano el esquema de base de datos para saber qué preguntarle al servidor con SQL.
Esquemas hay tantos como bases de datos definamos; y modelos de datos que marcan cómo se escriben o se dibujan esos esquemas también hay muchos. Nuestro curso no necesita más que el modelo relacional, el que te estamos mostrando, pero también hay Entidad-Relación, UML (Unified Modelling Language) y… muchos más. Quédate con que los modelos de datos son lenguajes muy especializados, algunos textuales, otros gráficos, cuya finalidad es representar sistemas de información, servir de gramática para los esquemas de bases de datos.
Y los esquemas, representaciones de sistemas de información. El nuestro es muy sencillo, al menos ahora, pero los esquemas suelen ser muy grandes, muy complejos. Este nos vale para lo que queremos.
Report abuse