Capitulo 2 Modelo relacional Introduccién y objetivos En este capitulo se presentan los principios basicos del modelo relacional. que es el modelo de datos en el que se basan la mayoria de los SGBD en uso hoy en dia. En primer lugar, se presenta la estructura de datos relacional y a continuaci6n las reglas de integridad que deben cumplirse sobre la misma. Al finalizar este capitulo, el estudiante debe ser capaz de # Definir qué es um modelo de datos y describir cémo se clasifican los modelos de datos. ® Definir los distintos modelos logicos de bases de datos. = Definir la estructura de datos relacional y todas sus partes. = Enumerar las propiedades de las relaciones. = Definir los tipos de relaciones. = Definir superclave, clave candidata, clave primaria y clave ajena. = Definir el coneepto de nulo. = Definir la regla de integridad de entidades y la regla de integridad refe- rencial. = Definir qué es una regla de negocio, = Dar un ejemplo completo de una base de datos formada por, al menos, dos relaciones con claves ajenas. © Meese guts EN 97-36-02-0146-3 8 Bose tos2.1. Modelos de datos Una de las caracteristicas fundamentales de los sistemas de bases de datos es que proporcionan cierto nivel de abstraccién de datos, al ocultar las earacte- ni sobre cl almacenamiento fisico que la mayoria de usuarios no necesita conocer. Los modelos de datos son el instrumento principal para ofrecer di- a abstraccién a través de su jerarquia de niveles. Un modelo de datos es un conjunto de conceptos que sirven para describir la estructura de una base de datos, es decir, los datos, las relaciones entre los datos y las restricciones que deben cumplirse sobre los datos. Los modelos de datos contienen también un conjunto de operaciones bisicas para la realizacién de consultas (lecturas) y actualizaciones de datos. Ademés, los modelos de datos més modernos inclu- yen mecanismos para especificar acciones compensatorias 0 adicionales que se deben llevar a cabo ante las acciones habituales que se realizan sobre la base de datos, Los modelos de datos se pueden clasificar dependiendo de los tipos de con- ceptos que ofrecen para describir la estructura de la base de datos, formando una jerarquia de niveles. Los modelos de datos de alto nivel, 0 modelos con- ceptuales, disponen de conceptos muy cercanos al modo en que la mayoria de los usuarios percibe los datos, mientras que los modelos de datos de bajo nivel, © modelos fisicos, proporcionan conceptos que describen los detalles de cémo se almacenan los datos en el ordenador. Los conceptos de los modelos fisicos estén dirigidos al personal informatico, no a los usuarios finales. Entre estos dos extremos se encuentran los modelos légicos, cuyos conceptos pueden ser entendidos por los usuarios finales, aunque no estén demasiado alejados de la forma en que los datos se organizan fisicamente. Los modelos logicos ocultan algunos detalles de como se almacenan los datos, pero pueden implementarse de manera directa en un SGBD. Los modelos conceptuales utilizan conceptos como entidades, atributos y relaciones. Una entidad representa um objeto o concepto del mundo real como, por ejemplo, un cliente de una empresa o una de sus facturas. Un atributo representa alguna propiedad de interés de una entidad como, por ejemplo, el nombre o el domicilio del cliente, Una relacién describe una interaceion entre dos 0 més entidades, por ejemplo, la relacién que hay entre un cliente y las facturas que se le han realizado. Cada SGBD soporta un modelo l6gico, siendo los mas comunes el relacional, el de red y el jerinquico. Estos modelos representan los datos valiéndose de estructuras de registros, por lo que también se denominan modelos orientados «@ registros. Hay una familia mas moderna de modelos logicos, son los modelos orientados a objetos, que estén més préximos a los modelos conceptuales. En el modelo relacional los datos se describen como un conjunto de tablas con referencias l6gicas entre ellas, mientras que en los modelos jerarquico y de red, los datos se describen como conjuntos de registros con referencias fi ellos (punteros). © Meese guts EN 97-36-02-0146-3 “ Bose tosLos modelos fisicos describen como se almacenan los datos en el ordena- dor: el formato de los registros, la estructura de los ficheros (desordenados, ordenados, agrupados) y los métodos de acceso utilizados (indices, tablas de dispersion). A la descripcion de una base de datos mediante 1n modelo de datos se le denomina esquema de la base de datos. Este esquema se especifica durante cl disefio, y no es de esperar que se modifique a menudo. Sin embargo, los datos que se almacenan en la base de datos pueden cambiar con mucha frecuencia: se insertan datos, se actualizan, se borran, ete. Los datos que la base de datos contiene en un determinado momento conforman el estado de la base de datos, © como también se denomina: una ocurrencia de la base de datos. La distincion entre el esquema y el estado de la base de datos es muy importante. Cuando definimos ima nueva base de datos, s6lo especificanos su esquema al SGBD, En ese momento, cl estado de la base de datos es el estado vaeio, sin datos. Cuando se cargan datos por primera vez, la base datos pasa al estado inicial, De ahi en adelante, siempre que se realice una operacion de actualizacion de la base de datos, se tendré un nuevo estado. El SGBD se encarga, en parte, de garantizar que todos los estados de la base de datos sean estados vilidos que satisfagan la estructura y las restricciones especificadas en el esquema, Por lo tanto, es muy importante que el esquema que se especifique al SGBD sea correcto y se debe tener gran cuidado al disefiarlo. El SGBD almacena el esquema en su catdlogo o diccionario de datos, de modo que se pueda consultar siempre que sea necesario. En 1970, el modo en que se veian las bases de datos cambié por completo cuando B. F. Codd introdujo el modelo relacional. En aquellos momentos, el enfoque existente para la estructura de las bases de datos utilizaba punteros fisicos (direcciones de disco) para relacionar registros de distintos ficheros. $i por ejemplo, se queria relacionar un registro A con un registro B, se debia ailadir al registro A un campo conteniendo la direecién en disco (un puntero fisico) del registro B, Codd demostré que estas bases de datos limitaban en gran medida los tipos de operaciones que los usuarios podian realizar sobre los datos. Ademas, estas bases de datos eran muy vulnerables a cambios en el entorno fisico. Si se afiadian los controladores de un nuevo disco al sistema y los datos se movian de una localizaci6n fisica a otra, se requeria una conversion de los ficheros dle datos. Estos sistemas se basaban en el modelo de red y el modelo jerarquico, los dos modelos logicos que constituyeron la primera gencracion de los SGBD. El modelo relacional representa la segunda generacién de los SGBD. En 41, todos los datos estén estructurados a nivel logico como tablas formadas por filas y columnas, aunque a nivel fisico pueden tener una estructura com- pletamente distinta. Un punto fuerte del modelo relacional es la sencillez de su estructura l6gica. Pero detras de esa simple estructura hay un fundamento te6rico importante del que carecen los SGBD de la primera generaci6n, lo que constituye otro punto a su favor. © Meese guts EN 97-36-02-0146-3 6 Bose tosDada la popularidad del modelo relacional, muchos sistemas de la primera generacién se han modificado para proporcionar una interfaz de usuario rela~ cional, con independencia del modelo logico que soportan (de red o jerdrquico) En los tiltimos afios, se han propuesto algunas extensiones al modelo re- lacional para capturar mejor el significado de los datos, para disponer de los conceptos de la orientacién a objetos y para disponer de capacidad deductiva. El modelo relacional, como todo modelo de datos, tiene que ver con tres as pectos de los datos, que son los que se presentan en los siguientes apartados de este capitulo: qué caracterfsticas tiene la estructura de datos, como mantener la integridad de los datos y cémo realizar el manejo de los mismos. 2.2. Estructura de datos relacional La estructura de datos del modelo relacional es la relacidn. En este apartado se presenta esta estructura de datos, sus propiedades, los tipos de relaciones y qué es una clave de una relacion. Para facilitar la comprensi6n de las definicio- nes formales de todos estos conceptos, se dan antes unas definiciones informales que permiten asinnilar dichos conceptos con otros que resulten familiares. 2.2.1. Relaciones Definiciones informales El] modelo relacional se basa en el concepto mateméatico de relacién, que gréficamente se representa mediante una tabla. Codd, que era un experto ma- tematico, utiliz6 una terminologfa perteneciente a las matematicas, en concreto de la teoria de conjuntos y de la légica de predicados, Una relacién es una tabla con columnas y filas. Un SGBD s6lo necesita que el usuario pueda percibir la base de datos como un conjunto de tablas. Esta percepcién s6lo se aplica a la estructura légica de la base de datos, no se aplica a la estructura fisica de la base de datos, que se puede implementar con distintas estructuras de almacenamiento. Un atributo es el nombre de una columna de una relacién. En el mode- lo relacional, las relaciones se utilizan para almacenar informacion sobre los objetos que se representan en Ia base de datos. Una relacion se representa grificamente como una tabla bidimensional en la que las filas corresponden a registros individuales y las columnas corresponden a los campos o atributos de esos registros. Los atributos pueden aparecer en la relacin en cualquier orden. Por ejemplo, la informacion de los clientes de una empresa determinada se representa mediante la relacién CLIENTES de la figura 2.1, que tiene columnas para los atributos codcli (cédigo del cliente), nombre (nombre y apellidos del cliente), direccién (calle y niimero donde se ubiea el cliente), codpostal (cédigo postal correspondiente a la direccion del cliente) y codpue (codigo de la poblacién del cliente). La informacion sobre las poblaciones se representa © Meese guts EN 97-36-02-0146-3 6 Bose tosinediante la relacion PUEBLOS de la misma figura, que tiene columnas para los, atributos codpue (cédigo de la poblacién), nombre (nombre de la poblacién) ¥ codpro (cédigo de la provincia en que se encuentra la poblacion). cLrewres codels | none directa cedportal | copae ‘353 [ Sos Carvetero, Jeala | Wosen Coupte, 17 ia0st 53596 336 | miguel trensiée, Ramin | Bernardo Mundina, 132-8 | 12682 | o7768 342 | Pinel teres, Vicente | Francisco Seapere, 37-10 | 12112 | o7766 345 | Lopes Botelta, Mauro | avensda del Puerto, 20-1 | 12439 | 17309 348 | Palau Martinez, Jorge | Raval de Sant Josep, 97-2 | 12401 | 17308 364 | Morria Vinaiza, Joes | Ciudadeta, 90-18 12990 | 12308 57_| Moguet Peris, Juan Anger | caite Mestre Rodrigo, 7 | 12930 | 12209 PUEBLOS codpue_| nontire | eodpre ‘o776s | Burriana [12 s2309 | casteltén | 12 46552 | Soneja 2 59596 | vsie-reat | 12 Figura 2.1: Relaciones que almacenan los datos de los clientes y sus poblaciones. Un dominio es el conjunto de valores legates de uno o varios atributos. Los dominios constituyen una poderosa caracteristica del modelo relacional. Cada atributo de una base de datos relacional se define sobre un dominio, pudiendo haber varios atributos definidos sobre el mismo dominio. La figura 2.2 muestra los dominios de los atributos de la relacion CLIENTES. Atributo | Dominio | Deseripeisn | Definicion codcli. ‘codli_dom Posibles cédigos de cliente. ‘Niimero hasta 5 digitos. nonbre | nombre_don | Nombres de personas: apelli | 50 caracteres dot apellido2, nombre. aireceién | direceién_don | Domicilios de Expaia: calle, | 50 caracteres. coapostal | codpostal_don | Codigos postales de Espaiia. | 5 caracteres coapue | codpue.don | Codigos de las poblaciones de | 5 caracteres. Expaita. Figura 2.2: Dominios de los atributos de la relacién que almacena los datos de los clientes. El concepto de dominio es importante porque permite que el usuario defina, en un Ingar comin, el significado y la fuente de los valores que los atributos pueden tomar. Esto hace que haya mas informacion disponible para el sistema cuando éste va a ejecutar una operacién relacional,, de modo que las operaciones que son seménticamente incorrectas, se pueden evitar. Por ejemplo, no tiene sentido comparar el nombre de una calle con un mimero de teléfono, aunque los dos atributos sean cadenas de caraeteres. Sin embargo, el importe mensual del alquiler de un inmueble no estara definido sobre el mismo dominio que © Meese guts EN 97-36-02-0146-3 v Bose tos1 niimero de meses que dura el alquiler, pero sf tiene sentido multiplicar los valores de ambos dominios para averiguar el importe total al que asciende el alquiler. Los SGBD relacionales no ofrecen un soporte completo de los dominios ya que su implementacién es extremadamente compleja. Una tupla es una fila de una relacién. Los elementos de una relacion son las tnplas o filas de la tabla. En la relacién CLIENTES, cada tupla tiene cinco valores, uno para cada atributo. Las tuplas de una relacion no siguen ningtin orden. El grado de una relacién es el niimero de atributos que contiene. La relacion CLIENTES es de grado cinco porque tiene cinco atributos. Esto quiere decir que cada fila de la tabla es una tupla con cinco valores. El grado de una relacion no cambia con frecuencia, La cartinalidad de una relacién es el niimero de tuplas que contiene. Ya que en las relaciones se van insertando y borrando tuplas a menudo, la cardinalidad de las mismas varia constantemente. Una base de datos relacional es un conjunto de relaciones normalizadas. Una relacion est normalizada si en la interseccién de cada fila con cada co- Immna hay un solo valor. Definiciones formales Una relacién R definida sobre un conjunto de dominios D;,D2,...,Dy consta de: = Cabecera: conjunto fijo de pares atributo:dominio {(Ai : D1), (Aa: D2), --+5 (An: Dn)} donde cada atributo A; corresponde a un tinico dominio D; y todos los A; son distintos, es decir, no hay dos atributos que se Hamen igual. El grado de la relacion R es n = Cuerpo: conjunto variable de tuplas. Cada tupla es un conjunto de pares atributo:valor: {(Aa #0), (Az ta), +++ (Ant vin) } con i= 1,2,...,m, donde m es la cardinalidad de la relacién R. En cada par (A; : vy) se tiene que vi; € Dj A continuacion se muestra la cabecera de la relacion CLIENTES de la figu- ra 2.1, y una de sus tuplas. { (codcli:codcli_dom), (nombre:nombre_dom) , (direccién:direccién_dom), (codpostal:codpostal_dom) , (codpue:codpue_dom) } © Meese guts EN 97-36-02-0146-3 8 Bose tos{ (codcli:333), (nombre:Sos Carretero, Jestis), (direccién:Mosen Compte, 14), (codpostal:12964), (codpue: 53596) } Este conjunto de pares no esta ordenado, por lo que la tupla anterior y la siguiente son la misma: { (nombre:Sos Carretero, Jestis), (codpostal:12964), (codeli:333), (direccién:Mosen Compte, 14), (codpue:53596) } Las relaciones se suelen representar gréficamente mediante tablas. Los nom- bres de las columnas corresponden a los nombres de los atributos, y las filas son cada una de las tuplas de la relacion. Los valores que aparecen en cada una de las columnas pertenecen al conjunto de valores del dominio sobre el que esta definido el atributo correspondiente. 2.2.2. Propiedades de las relaciones Las relaciones tienen las siguientes caracteristicas: ste es distinto del nombre de todas ® Cada relaci las demas. n tiene un nombre, y Los dominios sobre los que se definen los atributos son escalares, por lo que los valores de los atributos son atémicos. De este modo, en cada, tupla, cada atributo toma un solo valor. Se dice que las relaciones estén normalizadas, No hay dos atributos que se llamen igual. El orden de los atributos no importa: los atributos no estén ordenados. Cada tupla es distinta de las demas: no hay tuplas duplicadas. El orden de las tuplas no importa: las tuplas no estan ordenadas. © Meese guts EN 97-36-02-0146-3 ® Bose tos2.2.3. Tipos de relaciones En un SGBD relacional hay dos tipos de relaciones: = Relaciones base. Son relaciones reales que tienen nombre, y forman parte directa de la base de datos almacenada, Se dice que las relaciones base son relaciones autonomas. = Vistas. También denominadas relaciones virtuales, son relaciones con nombre y derivadas (no auténomas). Que son derivadas significa que se obtienen a partir de otras relaciones; se representan mediante sn de- finicién en términos de esas otras relaciones. Las vistas no poseen datos almacenados propios, los datos que contienen corresponden a datos al- macenados en relaciones base. 2.2.4. Claves ‘Ya que en una relacién no hay tuplas repetidas, éstas se pueden distinguir unas de otras, es decir, se pueden identificar de modo tnico. La forma de identificarlas es mediante los valores de sus atributos. Se denomina superclave a un atributo o conjunto de atributos que identifican de modo inico las tuplas de una relacion, Se denomina clave candidata a una superclave en la que ninguno de sus subconjuntos es una superclave de la relacién. El atributo 0 conjunto de atributos K de la relacion R es una clave candidata para R si, y s6lo si satisface las siguientes propiedades ® Unicidad: nunca hay dos tuplas en la relacion R con el mismo valor de K. = Irveducibitidad (minimatidad): ningin subconjunto de K tiene la propic- dad de unicidad, es decir, no se pueden eliminar componentes de K sin destruir la unicidad. Cuando una clave candidata esta formada por més de un atributo, se dic que es una clave compuesta, Una relacion puede tener varias claves eandidatas. Por ejemplo, en la relacién PUEBLOS de la figura 2.1, el atributo nombre no es tna clave candidata ya que hay pueblos en Espaiia con el mismo nombre que se encuentran en distintas provincias. Sin embargo, se ha asignado un cédigo tmico a cada poblacion, por lo que el atributo codpue si es una clave candidata de la relacion PUEBLOS. También es una clave candidata de esta relacion la pareja formada por los atributos nombre y codpro, ya que no hay dos poblaciones en la misma provincia que tengan el mismo nombre. Para identificar las claves candidatas de una relacién no hay que fijarse un estado u ocurrencia de la base de datos. El hecho de que en um momento dado no haya duplicados para un atributo o conjunto de atributos, no garanti- za que los duplicados no sean posibles. Sin embargo, la presencia de duplicados © Meese guts EN 97-36-02-0146-3 » Bose tosen un estado de Ia base de datos sf es aitil para demostrar que cierta combi- nacién de atributos no es una clave candidata. El tmico modo de identificar las claves candidatas es conociendo el significado real de los atributos, ya que esto permite saber si es posible que aparezean duplicados. Sélo usando esta informacion semAntica se puede saber con certeza si un conjunto de atributos forman una clave candidata, Por ejemplo, viendo la ocurrencia anterior de la relacion CLIENTES se podria pensar que el atributo nombre es una clave can- didata, Pero ya que este atributo es el nombre de un cliente y es posible que haya dos clientes con el mismo nombre, el atributo no es una clave candidata. Se denomina clave primaria de una relacion a aquella clave candidata que se escoge para identifiear sus tuplas de modo Gnico. Ya que una relacién no tiene tuplas duplicadas, siempre hay una clave candidata y, por lo tanto, la relacion siempre tiene clave primaria. En el peor easo, la clave primaria estara formada por todos los atributos de la relacion, pero normalmente habré un pequeiio subconjunto de los atributos que haga esta funcion Las claves candidatas que no son escogidas como clave primaria son de- nominadas claves alternativas. Por ejemplo, la clave primaria de la relacion PUEBLOS es el atributo codpue, siendo la pareja formada por nombre y codpro una clave alternativa. En la relacion CLIENTES s6lo hay una clave candidata que es el atributo codcli, por lo que esta clave candidata es la clave primaria. Una clave ajena es un atributo o un conjunto de atributos de una relacion cuyos valores coinciden con los valores de la clave primaria de alguna otra relacion (puede ser la misma). Las claves ajenas representan relaciones entre datos. Por ejemplo, el atributo codpue de CLIENTES relaciona a cada cliente con su poblacion. Este atributo en CLIENTES es una clave ajena cuyos valores hacen referencia al atributo codpue de PUEBLOS (su clave primaria). Se dice que un valor de clave ajena representa una referencia a la tupla que contiene el mismo valor en su clave primaria (tupla referenciada) Si nos fijamos en los datos de la figura 2.1, para conocer el nombre de la poblacién del cliente con codcli = 333, debemos seguir la clave ajena codpue que aparece en la tupla de dicho cliente y que tiene el valor 3596. Seguir la referencia que implica la clave ajena conlleva visitar la relacién PUEBLOS y localizar la fila que tiene el valor 53596 en su clave primaria. Notese que, en este ejemplo, la clave ajena tiene el mismo nombre que la clave primaria a la que hace referencia. Esto no es un requisito, las claves ajenas no precisan tener el mismo nombre que la clave primaria a la que referencian; sin embargo, si se utilizan los mismos nombres (0 nombres compuestos derivados de los mismos) es mas facil reconocer las claves ajenas. Al hablar de claves primarias y de claves ajenas es importante darse cuen- ta de que los valores de una clave primaria no se pueden repetir, mientras que no sucede lo mismo con las claves ajenas que le hacen referencia. Asf, en las tablas de la figura 2.1 no es posible encontrar dos tuplas con el mismo valor en PUEBLOS. codpue (cada poblacién debe aparecer en la relacion una sola vez), pero si es posible encontrar varias tuplas con el mismo valor en © Meese guts EN 97-36-02-0146-3 a Bose tosCLIENTES.codpue, ya que es posible que haya varios clientes que se ubiquen en la misma poblacién. 2.3. Esquema de una base de datos relacional Una base de datos relacional es un conjunto de relaciones. Para representar el esquema de una base de datos relacional se debe dar el nombre de sus relaciones, los atributos de éstas, los dominios sobre los que se definen estos atributos, las claves primarias y las claves ajenas. El esquema de la base de datos de la empresa con la que trabajaremos en este libro es el siguiente CLIENTES(codcli, nombre, direccién, codpostal, codpue) VENDEDORES(codven, nombre, direccién, codpostal, codpue, codjefe) PUEBLOS (codpue, nombre, codpro) PROVINCIAS(codpro, nombre) ARTICULOS(Codart, descrip, precio, stock, stock_min, dto) FACTURAS(codfac, fecha, codcli, codven, iva, dto) LINEAS_FAC(codfac, Linea, cant, codart, precio, ato) En el esquema anterior, los nombres de las relaciones aparecen seguidos de los nombres de los atributos encerrados entre paréntesis. Las claves primarias son los atributos subrayados. Las claves ajenas se representan mediante los siguientes diagramas referenciales: codpue curenres SP" pygptos Poblaciéu del cliente codpue venpepores “°°P"° — pygpLos Poblacion del vendedor codjefe venpepores “°JS*® yenpEpoRES : Jefe del vendedor. ‘odpro puestos }§= ““PF°—provinctaS : Provincia en la que se encuentra la po blacio racturas = 214 tewres Cliente al que pertenece la factura. Facturas C32 vewpEDORES =: Vendedor que ha realizado la venta. Lingas_rac CO2f2¢ pacruas Factura en la que se encuentra la linea. Lingas_rac CC927* gpricutos Articulo que se compra en la linea de factura. La tabla PROVINCIAS almacena informacion sobre las provineias de Es- pala, De cada provincia se almacena su nombre (nombre) y un cédigo que la identifica (codpro). La tabla PUEBLOS contiene los nombres (nombre) de los pueblos de Espaiia, Cada pueblo se identifica por un eddigo que es tinico (codpue) y tiene una referencia a la provincia a la que pertenece (codpro) La tabla CLIENTES contiene los datos de los clientes: cédigo que identifica a © Meese guts EN 97-36-02-0146-3 2 Bose toscada uno (codc1i), nombre y apellidos (nombre), calle y nimero (4ireccién), cédigo postal (codpostal) y una referencia a su poblacién (codpue). La ta- bla VENDEDORES contiene los datos de los vendedores de la empresa: c6digo que identifica a cada uno (codven), nombre y apellidos (nombre), calle y nit mero (direccién), cédigo postal (codpostal), ima referencia a su poblacion (codpue) y una referencia al vendedor del que depende (codjefe), si es cl caso. En la tabla ARTICULOS se tiene el codigo que identifica a cada articu- lo (codart), su descripcién (descrip), el precio de venta actual (precio), el niimero de unidades del articulo que hay en el almacén (stock), la cantidad minima que se desea mantener almacenada (stock_min) y, si el articulo esta en oferta, el descnento (dto) que se debe aplicar cuando se venda. La tabla FACTURAS contiene las cabeceras de las facturas correspondientes a las com- pras realizadas por los clientes. Cada factura tiene un c6digo ‘nico (codfac), la fecha en que se ha realizado (fecha), asi como el IVA (iva) y el descuen- to que se le ha aplicado (ato). Cada factura hace referencia al cliente al que pertenece (codeli) y al vendedor que la ha realizado (codven). Las lineas de cada factura se encuentran en la tabla LEINEAS_FAC, identificéndose cada una por el niimero de linea que ocupa dentro de la factura (codfac, Linea). En cada una de ellas se especifica la cantidad de unidades (cant) del articulo que se compra (codart), el precio de venta por unidad (precio) y el desenento que se aplica sobre dicho precio (ato), si es que el articulo estaba en oferta enando se vendid, A continuacién se muestra un acaba de definir, stado de la base de datos cuyo esquema se codes | nonbre aireccisa, codpostal_ | coapae 355 Nosen Coupte, 1 296d | 59556 336 Bernardo Mundina, 132-6 | 12682 | o7766 342 | Pinel Huerta, Vicente | Francisco Sompore, 37-10 | 12112 | o7766 348 | Lopez Botelta, aur | Avenida del Puerto, 20-1 | 12010 | 12209, 348 | Polau Martinez, Jorge | Raval de Sant Josep, 07-2 | 12003 | 12300 354 | morria Vinaize, Joos | Ciudadela, 90-18 12003 | 12300 357_| muguet Peris, Juan inget | caite Mestre Rodrigo, 7 | 12100 | 12309 codven | nombre areccioa, vipoatall_codpus odje 5 | Guillén Vilar, Waealia ] Sant Josep, 170 12507 | 3696 | 105 105 | Poy Onotia, Patoza | Sanchis Tarazona, 103-1 | 12257 | 46352 155 | nubert Cano, Diego | Bonicar16 Residencial, 164 | 12425 | iraso | 5 4s5__| agost Tirade, Jorge | Pasaje Petagolosa, 2119 | 12014 | sasve | 5. PUEBLOS coapue | nombre | eoapre a7ves | Burriana [32 49552 | Soneja 2 59596 | vsie-reat | 12 © Meese guts EN 97-36-02-0146-3 a Bose tosPROVINCTAS: © Meese guts EN 97-36-02-0146-3 u codpre | moxbre 03 Alicante 32 | Castella 46__| Valencia anticuos codart | descrip precio | stock | stecknin | ato THSPSR | Interruptor magnetoteraice @p, 2 [27-01 ft T imPiol | interrupter aagnetotéenica 4p, 4 | 32.60 | 1 a] ss tids40 | Bases de fussbles cuchi1iae TO os} 3 3 ti7oss | Bases de fusible cuehillns 73 roe] 3 3 Lreaze | Placa 2, logrand serie mosaic | 2.90| 5 2 asas9 | Tocla Legrand sarfil 20] 0 4 Lassie | Tecla dituscree Legrand bronce ros | 13 s| s toriia | Portatémparas 14 curvo se] 2 4 e200 | Marco Bje Thien 2 elementos sso] 4 1 nso72 | Pulaador uz piloto Niessen trazo | 1.3 | 11 2 wo0176A | Reto} Orbis con reserva de cveraa | 3.40] 7 4 Pos | Caja 1 olen, plastinetal 165 | 16 8 Peas | Interruptor rotura brusca 100 Am | 13.22] 1 1 po2¢_— | Interruptor warren dec. con visor | 2.99] 8 3 Rerixq0_ | Regleta flucrescente 1336 bajo F | 71 | 1 1 s216si26 | Bloque energencia Satf 150 L aa] 6 a ras01 | tubo empotrar 100 298] 0 5 Tera00 | tobte conmstaor sje tise bianco | 19.22 | a titi | Carva eubo nierrs 29 raz) 20 3 mica | Pinca murat Felnax se) 4 1 zxct___| base Tut lateral Ticino 8, Tome | aii | i il FACTURAS esis | aeror/au1o | ass [i081] 10 ests | is/or/2010 | 336 | 105 | o| 20 essa | sivor/aio | ssr | ass | 8| 0 659 | 05/os/20i0 | 342 | 5 of o 680 | 10/05/2010 | 348 | ass | 6| 0 e723 | os/irao | 242 | 5 | 1¢| 0 era2_| rr/izyaio | 333 | 10s |_| 20 LINEAS FAC coafec | Tinen | cant | eotare [precio [ ate 358 tT] piso} 0.81 | 20 6643 2| 4 | xsore uaa | “0 6543 3| 2 | Peos siz] o 6565 2| 6 | noorr, | sao] 0 6645 3| 3] ter200 | i322] 0 66545 4] 4]uo2 | S08] 0 6654 1| 6 | rerio | e.71| so 6659 1| 2 | tacar use | 0 6659 2| 12] 1705s | 7:90 | a5 6689 3| 9] tres | 2:90] 0 680 2| 11 | smapio. | 32.60] 0 e773 | 5 | tosis9 | 2.00] 5 ere 1| 9| e200 | i352] 0 Bose tos2.4. Reglas de integridad Una vez definida la estructura de datos del modelo relacional, pasamos a estudiar las reglas de integridad que los datos almacenados en dicha estructura deben cumplir para garantizar que son correctos. Al definir cada atributo sobre un dominio se impone una restriccién sobre el conjunto de valores permitidos para cada atributo. A este tipo de restricciones se les denomina restriceiones de dominios. Hay ademas dos reglas de integridad muy importantes que son restricciones que se deben cumplir en todas las bases de datos relacionales y en todos sus estados (las reglas se deben cumplir todo cl tiempo). Estas reglas son la regla de integridad de entidades y la regla de integridad referencial. Antes de definirlas, es preciso conocer el concepto de nulo. 2.4.1. Nulos Cnando en una tupla un atributo es desconocido, se dice que es nulo. Un nulo no representa el valor cero ni la cadena vacia ya que éstos son valores que tienen significado. Bl nulo implica ansencia de informacion, bien porque al insertar la tupla se desconocia el valor del atributo, o bien porque para dicha tupla el atributo no tiene sentido. Ya que los nulos no son valores, deben tratarse de modo diferente, lo que : ‘on, De hecho, no todos los SGBD relacional 2.4.2. Regla de integridad de entidades La primera regla de integridad se aplica a las claves primarias de las re- laciones base: ninguno de los atributos que componen la clave primaria puede ser nulo, Por definicion, una clave primaria es una clave irreducible que se utiliza para identificar de modo tinico las tuplas. Que es irreducible significa que ningiin subconjunto de la clave primaria sirve para identificar las tuplas de modo tinico. Si se permitiera que parte de la clave primaria fuera nula, se estarfa diciendo que no todos sus atributos son necesarios para distinguir las tuplas, con lo que se estarfa contradiciendo la irreducibilidad. Notese que esta regla sélo se aplica a las relaciones base y a las claves primarias, no a las claves alternativas. © Meese guts EN 97-36-02-0146-3 * Bose tos