Sei sulla pagina 1di 13

ón.

r§fiUffiA
ios
f.ffi
'íles
slil-
ase

Los
de-
rles
?an
itos

30n
,,de

)m-
;te-
"ea
:de
rdo
tos
de
na-
los

to-
ica
'i-es
Ce
lSe

Un DBMS moderno proporciona almacenamiento no sólo para los datos, sino también para formatos de intro-
ducción de datos relacionados o definiciones de pantalla, definiciones de inform¿s, reglas de validación de datos,
código de procedimiento, estructuras para manejar video y formatos de imágenes, etc. La administración de
,la- almacenamiento de datos también es importante para afinar la operación de una base de datos. La afinación
rte de operación se relaciona con las actividades que hacen que la base de datos opere más eÍicientemente en
,ls-
términos de rapidez de almacenamiento y acceso. Aun cuando el usuario ve la base de datos como una sola
ón unidad de almacenamiento, el DBMS en realidad guarda la base de datos en múltiples archivos físicos de datos.
no (véase la figura 1.9). Estos archivos de datos pueden incluso guardarse en diferentes medios de almacenamiento.
i€S Por tanto, el DBMS no tiene que esperar una petición de disco para terminar antes que se inicie la siguiente. En
otras palabras, el DBMS puede satisfacer las peticiones de bases de datos en forma concurrente. Los aspectos
.,,US
de la administración del almacenamiento de datos y la afinación de operación se estudian en el capítulo 11,
lcs Afinación de operación de una base de datos y optimización de consulta.
ar
-L-it
Transformacíón y presentación de datos. El DBMS transforma los datos introducidos para apegarse a las
estructuras de datos requeridas. El DBMS libera al usuario dei trabajo de hacer una distinción entre el formato
.ar
de datos lógico y el formato de datos físico. Esto es, el DBMS da formato a los datos físicamente recuperados
Ce
para hacer que se apeguen a las expectativas lógicas del usuario. Imaginemos una base de datos utilizada por
-,ü€
-,ia una compañía multinacionai. Un usuario final en Inglaterra esperaría introducir datos como, por ejemplo, 11
de julio de 2070, como "17/07 /2010" . En contraste, la misma fecha se introduciría en Estados Unidos como
,.lS-
"07 /77/2070". Cualquiera que sea el {ormato de presentación de datos, el DBMS debe manejar la fecha en el
formato apropiado para cada país.
,as Administración de segurídod. El DBMS crea un sistema de seguridad que hace cumplir la seguridad del usuario
a-
..L{
y la privacidad de datos. Las reglas de seguridad determinan cuáles usuarios pueden tener acceso a la base de
datos, a qué elementos puede tener acceso el usuario y cuáles operaciones (leer, agregar, elimina¡ o modificar)
puede realizar el usuario. Esto es especialmente importante en sistemas de base de datos de usuarios múltiples.
FEGUR,&
,H"9

La
La base de datos ORAIAB en La interfaz Oracle DBA Studio mit
realidad se guarda en nueve Management también muestra Ap
archivos ubicados en la uni- Ia cantidad de espacio emplea-
dad C: de la computadora del da por cada uno de los archivos
servidor de base de datos. qr¡e constituyen la base de W
datos lógica individual.

El capítulo 15, Administración y seguridad de bases de datos, examina más detalladamente los problemas de W
seguridad y privacidad de los datos. Todos los usuarios de una base de datos pueden ser autentificados frente al
La
DBMS por medio de un nombre de usuario y una contraseña, o mediante autentificación biométrica como lo
1m
es un escaneo de huella digital. El DBMS emplea esta información para asignar priülegios de acceso a varios
e{\
componentes de bases de datos como consultas e informes.
orf
Control de acceso a múltiples usuoríos. Para dar integridad y consistencia de datos, el DBMS utiliza algorit-
mos complejos para asegurar que múltiples usuarios tengan acceso concurrentemente a la base de datos sin EI
comprometer la integridad de ésta. El capítulo 10, Administración de transacciones y control de concurrencia, de
aborda los detalles del control de acceso a usuarios múltiples. da
Administración de respaldo y recuperación. El DBMS suministra respaldo y recuperación de datos para garan- m¿
tizar la seguridad e integridad de los datos. Los DBMS actuales cuentan con utilerías especiales que permiten al
administrador de la base de datos (DBA) ejecutar la rutina y procedimientos de respaldo y restauración. La ad- Ar-
+--
ministración de recuperación se ocupa de la restauración de la base de datos después de una falla; por ejemplo, Lg.t

un mal sector del disco o una falla de energía eléctrica. Esta capacidad es de importancia crítica para preservar
la integridad de la base de datos. El capítulo 15 se ocupa de problemas de respaldo y recuperación.
Adminístración de la integrídad de datos. El DBMS promueve y hace cumplir las reglas de integridad, redu-
ciendo al mínimo la redundancia y maximizando la consistencia de los datos. Las relaciones de datos guardadas
en el diccionario de datos se usan para hacer cumplir la integridad de los datos. Asegurar la integridad de los
datos es especialmenie importante en sistemas de bases de datos orientados a transacciones. Los problemas
de administración de integridad y transacción de datos se abordan en el capítulo 7, Introducción al lenguaje de
consulta est¡uctürado (SQL) V en el capítulo 10.
Lenguajes de acceso a base de datos e interfaz de programación de a¡tlícacíón. El DBMS proporciona acceso
a los datos por medio de un lenguaje de consulta. Un fenguaie de consulta no es un lenguale de procedi-
miento; es un lenguaje que permite al usuario especificar qué debe hacerse sin tener que especificar cómo debe
hacerse. Un lenguaje
-de
de consulta estructurado (§QL) es, de hecho, el lenguaje de consulta y norma
acceso a datos apoyado por la mayoría de vendedores de DBMS. El capítulo 7, Introducción al lenguaje de
,onrultu estructurado (SQL), y el capítulo 8, SQL avanzado, se ocupan de SQL. El DBMS también contiene
interfazde programación de aplicación a lenguajes de procedimiento como COBOL, C, Java, Visual Basic.NET
v C*. Además, el DBMS contiene utilerias administrativas empleadas por el DBA y el diseñador de bases de
áatos para crear, implementar, monitorear y mantener la base de datos.
lnterfaz de comunicacíón de una base de dofos. Los DBMS de la generación acfual aceptan peticiones de un
usuario final hechas a travás de múltiples y diferentes ambientes dered. Por ejemplo, el DBMS podría dar acceso
u lu bu.n de datos a través de internet mediante navegadores web como Mozilla Firefox o Microsoft Internet
Explorer. En este ambiente, las comunicaciones pueden realizarse de varias formas,
- Los usuarios finales pueden generar respuestas a consultas al llenar formas en pantalla mediante su navega-
dor web preferido.
- El DBMS puede publicar informes automáticamente predefinidos en un sitio web.
- El DBMS puede conectar a sistemas de terceros para distribuir información vía cibercorreo u otras aplicacio-
nes de productiüdad.

ffi§ü int"rf* de comunicación de una base de datos se examinan en mayor detalle en el capítulo 12, Sistemas para ad-
de bases datos distnbuida e1 garit^ulo 14,.cg¡ectiviaaa a3 y en el
ffi{iSrnistru.ion fl i 3l !11s 9" 9L:: Y 11.*:lTl1leb

Por qué una hoia de cálculo no es una base de datos


Si bien una hoja de cálculo permite la creación de múltiples tablas, no soporta incluso la funcionalidad más
esencial de una base de datos como el soporte para autodocumentación a través de metadatos, imposición de
tipos o dominios de datos para asegurar la consistencia de los datos dentro de una columna, relaciones defini-
dás entre tablas, o restricciones para asegurar la consistencia de los datos en tablas relacionadas. La mayoría
de los usuarios carecen de la capacitación necesaria para reconocer las limitaciones de las hojas de cálculo
para estos tipos de tareas.

üE Aorr,*,"t*oa,ó* oat o= ot ,ototr ,* a* a"roer=


de ","taro "o.t "or",o
-al
,lo La introducción de un sistema de base de datos sobre el sistema de archivos produce un marco en el que se pueden
imponer estrictos procedimientos y normas. En consecuencia, la función del componente humano cambia de un énfasis
, ios
en programación (en el sistema de archivos) a un enfoque en los aspectos más generales de los recursos de datos de [a
organización y en la administración del complejo software de bases de datos.
iit-
;in El sistema de bases de datos hace posible el uso mucho más complejo de los recursos de los datos, mientras la base
, ia, de datos esté diseñada para ocupar la fuerza disponible. Las clases de estructuras de datos creadas dentro de la base de
datos y la magnitud de relaciones entre ellas desempeñan una poderosa función para determinar la eficacia del siste-
;--'rll- ma de base de datos.
al
.,d- Aun cuando el sistema de base de datos da considerables ventajas sobre anteriores méiodos de administración de datos,
,1o, iambién tiene desventajas considerables. Por ejemplo:
'tar . Cosfos mós altos. Los sistemas de base de datos requieren hardware y sofhvare complejos y personal altamente
capacitado. El costo de mantener hardware, sofh¡,¡are y personal requerido para operar y manejar un sistema
.1-
:U-
.
de base de datos puede ser considerable. Los costos de capacitación, licencia y apego a reglamentos suelen
, c15 descuidarse cuando se implementan sistemas de base de datos.
.CS " Complejidad de administración. Los sistemas de base de datos interactúan con numerosas tecnologías y tie-
, .&S nen un considerable impacto en los recursos y en la cultura de una compañía. Los cambios introducidos por la
,1, adopción de un sistema de base de datos deben ser manejados en forma apropiada para asegurar que ayuden
a alcanzar los objeiivos de la compañía. Dado e[ hecho de que los sistemas de bases de datos contienen datos
,_
30 de importancia esencial de una compañía, a los que se tiene acceso desde múltiples fuentes, los problemas de
-il-
seguridad deben evaluarse constantemenie.
' .. \,D
Mantener una actualización general. Para maximizar la eficiencia de un sistema de base de datos es necesario
mantener actualizado ese sistema. Por tanto, el usuario debe realizar constantes actualizaciones y aplicar los
últimos parches y medidas de seguridad a todos los componentes. Como la tecnología de bases de datos avaraa
rápidamente, los costos de capacitar personal tienden a ser considerables.
Dependencía de uendedores. Dada la fuerte inversión en tecnología y capacitación de personal, las empresas
podrían ser reacias a cambiar vendedores de bases de datos. En consecuencia, es menos probable que los ven-
dedores ofrezcan precios ventajosos a clientes ya eústentes y éstos podrían estar limitados en sus elecciones de
componentes de sistemas de base de datos.
Ciclos frecuentes de actualizacióilremplazo. Los vendedores de los DBMS actualizan sus productos cuando
agregan nueva funcionalidad. Es frecuente que estas nuevas funciones se ofrezcan en paquete en recientes ver-
siones actualizadas del software. Algunas de estas versiones requieren acfualizaciones del hardware, que no sólo
cuestan dinero sino que también hacen necesario capacitar usuarios y administradores de bases de datos, para
emplear y manejar correctamente las nuevas funciones. ffi.

Ahora que hemos considerado qué es una base de datos y un DBMS y por qué son necesarios, es nafural que abor-
demos las ventajas del diseño de una base de datos. No obstante, antes que podamos crear un diseño, debemos saber W
cuáles herramientas están a nuestra disposición. En todo este capíhrlo hemos generalizado el esfudio de la tecnología de
una base de datos, de modo que parece que es un método indiüdual y común para el diseño de una base de datos. No
obstante, como diseñador y perfeccionador de una base de datos, el usuario debe entender que hay diferentes métodos
y üene que conocer la forma como éstos influyen en los diseños que haya creado y cómo se modelan.

ad
a{i
alr
aL)
dfr
ba
ba
ba
ba
ba
ba
ba
ba,
L-
UA,

ba,
ba,
ba:
cal
caI
. . -!:il

.i i:i._fi:i:ii

:111t:rÍ#:

SE

Cel

ias

Este capítulo examina el modelado de datos. El modelado de datos es el primer paso en

el üaje del diseño de bases de datos, ya que sirve como puente entre objetos reales y la
base de datos que reside en la computadora.

Uno de los problemas más molestos del diseño de bases de datos es que los diseñado-
res, programadores y usuarios finales ven los datos en distintas formas. En consecuen-
cia, vistas diferentes de los mismos datos pueden llevar a diseños de bases de datos que
no reflejan la operación real de una organización, al no satisfacer las necesidades del
usuario final ni las necesidades de eficiencia de datos. Para evitar esto, los diseñadores
de bases de datos deben obtener una descripción precisa de la naturaleza de los datos y
de los muchos usos que tienen dentro de la organización. La comunicación entre dise-
ñadores de bases de datos, programadores y usuarios finales debe ser trecuente y clara.
El modelado de datos aclara esta comunicación, al reducir las complejidades del diseño
de bases de datos a abstracciones que se entienden con más facilidad y que definen
entidades y las relaciones entre ellas.

En primer término, el lector aprenderá algunos conceptos básicos del modelado de


datos y cómo se desarrollaron los modelos actuales a partir de los anteriores. Rastrear
el desarrollo de esos modelos de bases de datos ayuda a entender problemas del diseño
e implementación de bases de datos, mismos que se abordan en el resto del libro. En
segundo lugar, introduciremos al lector al diagrama enüdad-relación (ERD por
sus siglas en inglés) como herramienta para el modelado de datos. Los diagramas ER se
pueden trazar usando varias notaciones. En este capítulo introduciremos al estudiante a
la notación Chen tradicional, a la notación más actual de "Pata de gallo" y a la notación

más reciente de diagrama de clase, que es parte del Lenguaje de modelado unificado
(UML). Por último, aprenderemos el modo en que varios grados de abstracción de datos
ayudan a reconciliar üstas diversas de los mismos datos.
El diseño de bases de datos se concentra en la lorma en que la estructura de bases de datos se usará para guardar y ad-
ministrar datos del usuario final. El modelado de datos, primer paso para diseñar una base de datos, se reÍiere al proceso
de crear un modelo específico de datos para el dominio de un problema determinado. (Un dominio de problema es un
área claramente definida dentro del ambiente real, con ámbito y fronteras bien delimitados, que se ha de manejar siste-
máticamente.) Un modelo de datos es una representación relativamente sencilla, por lo general gráfica, de estruc-
turas de datos reales más complejas. En términos generales, wt modelo es una abstracción de un objeto o hecho real
más complejo. La función principal de un modelo es ayudar a que el lector entienda las complejidades del ambiente real.
Dentro del ambiente de una base de datos, el modelo representa estructuras de datos y sus características, relaciones,
restricciones, transformaciones y otras construcciones con el propósito de sostener un dominio de problema específico.

Es frecuente que los términos modelo de datos y modelo de base de datos se usen indistintamente. En este
libro, el término mo delo de base de datos se usa para referirse a la implementación de un modelo de datos
en un sistema específico de base de datos.

El modelado de datos es un proceso iterativo y progresivo. Se empieza con una comprensión sencilla del dominio del
problema y a medida que aumente ésta, también se incrementa el nivel de detalle del modelo de datos. Si se hace en-
forma apropiada, el modelo de datos final es en efeclo un "plano" que contiene todas las instrucciones para construir
una base de datos que va a satisfacer todas las necesidades del usuario final. Este plano es narrativo y gráfico en su
naturaleza, lo cual significa que contíene descripciones de texto en lenguaje sencillo, no ambiguo y claro, que describe
los elementos principales de los datos.

Un modelo de datos listo para implementación debe contener al menos los siguientes componentes:
. Una descripción de la estructura de datos que guardará los datos del usuario final.
. Un conjunto de reglas que se pueden hacer cumplir para garantizar la integridad de los datos.
. Una metodología de manipulación de datos para apoyar las transformaciones de los datos reales.

Por tradición, los diseñadores de datos se apoyaban en el sentido común para desarrollar un buen modelo de datos. Des-
afortunadamente, el sentido común es un concepto relativo y con frecuencia se desarrolla después de muchas pruebas
y errores. Por ejemplo, si cada uno de los estudiantes de un grupo ha de crear un modelo de datos para un almacén de
video, es muy probable que cada uno de ellos llegue con un modelo diferente. ¿Cuál sería eI correcto? La respuesta más
sencilla es "el que satisfaga todas las necesidades del usuario final" y puede haber más de una solución correcta. Por
fortuna, los diseñadores de bases de datos utilizan construcciones ya existentes del modelado de datos y de poderosas
herramientas para el diseño de bases de datos que reducen considerablemente el potencial de errores en el modelado
de bases de datos. En las secciones siguientes aprenderemos cómo se usan los modelos de datos para representar datos
reales y cómo los diferentes grados de abstracción de datos facilitan el modelado de datos.

Los modelos de datos pueden facilitar la interacción entre el diseñador, el programador de aplicaciones y el usuario
final. Un modelo bien diseñado puede incluso promover un mejor entendimiento de la organización para la cual se de-
sarrolló el diseño de la base de datos. En pocas palabras, los modelos de datos son una herramienta de comunicación.
Este importante aspecto del modelado de datos fue resumido claramente por un cliente cuya reacción fue la siguiente:
"Fundá este negocio, trabajé durante años y ésta es la primera vez qve en realidad he entendido cómo se ajustan en
realidad todas las partes".
l-a importancia del modelado de datos no se puede exagerar. Los datos constituyen las unidades de información más
elementales que un sistema emplea. Las aplicaciones son creadas para manejar datos y ayudar a transformarlos en
información. Pero los datos son vistos en distintas formas por personas diferentes. Por ejemplo, contraste la vista (de
I
i-
I datos) del gerente de una compañía con la de un empleado. Aun cuando gerenie y empleado trabajan para la misma
l compañía, es muy probable que el gerente tenga una visión más general de los datos que el empleado.
:I
,.- Incluso distintos gerentes ven datos de forma diferente. Por ejemplo, es probable que el presidente de una compañía
tenga una üsión universal de los datos porque debe relacionar los departamentos de la compañía a una üsta común
'l
{l 1!ase de datos). Es probable que un gerente de compras de la misma compañía tenga una üsta más restringida de los
t. datos, al igual que el gerente de inventarios. En efecto, el gerente de cada departamento trabaja con un subconjunto
de los datos de la compañía. El gerente de inventarios está más ocupado con los niveles de inventario, en tanto que el
gerente de compras se ocupa del costo de las compras y de las relaciones personales/de negocios con los proveedores
de esas compras.
,:jE
!'i€

:j&l
Los programadores de aplicaciones tienen también otra vista de los datos, más relacionada con la ubicación de datos,
formateo y necesidades específicas de informes. Básicamente, los programadores de aplicaciones transforman políti-
cas y procedimientos de la compañía, de una variedad de fuentes, en interfaces e informes apropiados, así como en
pantallas de consulta.

Los diferentes usuarios y productores de datos e información a veces reflejan la analogía de "la persona ciega y el
elefante": la persona ciega que sintió la trompa del elefante tenía una üsión muy diferente del paquidermo, respecto
rl
de aquella que sintió una pata o la cola. Lo que se necesita es una visión de todo el elefante. Del mismo modo, una
il
casa no es un conjunto de habitaciones al azar; si alguien va a construir una casa debe tener una vista general que es
,r
proporcionada por planos. Igualmente, un buen ambiente de datos requiere un plano general de base de datos apoyado
J
en un modelo apropiado de datos.
-2

Cuando se dispone de un buen plano de base de datos, no importa que la vista que el programador de aplicaciones
tenga de los datos sea diferente de la del gerente o de la del usuario final. Por otra parte, cuando no se dispone de un
buen plano es probable que surjan problemas. Por ejemplo, un programa de administración de inventarios y un sistema
de introducción de pedidos pueden usar esquemas conflictivos de enumeración de productos, lo cual costará a la com-
pañía miles (y hasta millones) de dólares.

Recuerde que el plano de una casa es una abstracción; no se puede vivir en é1. Del mismo modo, el modelo de datos es
una abstracción; no se pueden sacar de él los datos requeridos. Así como no es probable construir una buena casa sin
un plano, es igualmente improbable crear una buena base de datos sin elaborar primero un modelo apropiado de datos.

.,S

:) Los elementos básicos de todos los modelos de datos son: entidades, atributos, relaciones y restricciones. Una entidad
,.1
es cualquier cosa (una persona, lugar, cosa o hecho) acerca de la cual se han de colectar y guardar datos. Una entidad
r'
representa un tipo particular de obleto en el mundo real. Como una entidad representa un tipo particular de objeto, las
il
entidades son "distinguibles", es decir, cada vez que se presenta una de ellas es única y distinta. Por ejemplo, una entidad
CLIENTE tendría muchas ocurrencias distinguibles, por ejemplo, John Smith, Pedro Dinamita, Tom Strickland, etc. Las
entidades pueden ser objetos físicos, como clientes o productos, pero las entidades también pueden ser abstracciones,
como ¡utas de vuelo o conciertos musicales.

Un atributo es una característica de una entidad. Por ejemplo, una entidad CLIENTE sería descrita por atributos tales
como apellido paterno, nombre, teléfono, dirección y límite de crédito del cliente. Los atributos son el equivalente de
los campos en los sistemas de archivos.

Una relación describe una asociación entre entidades. Por ejemplo, existe una relación entre clientes y agentes que
se puede describir como sigue: un agente puede atender a numerosos clientes y cada cliente puede ser atendido por un
agente. Los modelos de datos usan tres tipos de relaciones: uno a muchos, muchos a muchos y uno a uno. Los diseña-
dores de bases de datos por lo general usan las notaciones breves 1:M o 1..'* M:N o *,.* y 1:1 o 1..1, respectivamente.
(Aun cuando la notación M:N es una leyenda estándar para la relación de muchos a muchos, la notación M:M también
puede usarse.) Los siguientes ejemplos ilustran las distinciones entre las tres.
!

Relación uño a muchos (1:M o 1..*). Un pintor crea muchas obras, pero cada una de ellas es pintada por
sólo un pintor. Así, el pintor (el "uno") está relacionado con las pinturas (las "muchas"). Por tanto, los diseña-
dores de bases de datos marcan la relación (PINTOR pinta PINTURA) como 1:M. (Nótese que los nombres de
entidad con frecuencia se ponen en mayúsculas como convención, de modo que se identifiquen con facilidad.)
Del mismo modo, un cliente (el "uno") puede generaÍ muchas facturas, pero cada {actura (el "muchos") es gene-
rada por un solo cliente. La relación (CUENTE genera FACTURA) también sería marcada corno 1:M.

Relación muchos a muchos (M:N o *..*). Un empleado puede aprender muchas habilidades en el trabajo
y cada habilidad de trabajo puede ser aprendida por muchos empleados. Los diseñadores de bases de datos mar-
can la relación (EMPLEADO aprende HABILIDAD) como M:N. Del mismo modo, un estudiante puede tomar
muchas clases y cada clase puede ser tomada por muchos estudiantes, dando así la leyenda de relación M:N para
la relación expresada por (ESTUDIANTE toma CLASE).

Relación un«» a uno (1:l o 1..1). La estructura de administración de una compañía de ventas al por menor
puede requerir que cada una de sw tiendas sea manejada por un solo empleado. A su vez, el gerente de cada
tienda, que es un empleado, maneja sólo una tienda. Por tanto, la relación (EMPLEADO maneja TIENDA) se
marca como 1: 1.

[-a exposición precedente identificó cada relación en ambas direcciones; esto es, las relaiiones son bidireccionales:
. Un CUENTE puede generar muchas FACTURAS.
r Cada una de las muchos FACTUBAS es generada sólo por un CLIENTE.

Una restricción se aplica a los datos. Las restricciones son importantes porque ayudan a asegurar la integridad de
datos. Las restricciones se expresan normalmente en forma de reglas. Por ejemplo:
o El salario de un empleado puede tener valores que están enlre 6 000 y 350 000.
, EI PDC (promedio de calificaciones) de un estudiante puede estar entre 0.00 y 4.00.
. Cada clase debe tener un y sólo un maestro.
¿Cómo identificamos correctamente entidades, atributos, relaciones y restricciones? El primer paso es identificar con
claridad las reglas de negocios para el dominio de problema que se modele

Cuando los diseñadores de bases de datos empiezan a seleccionar o determinar las entidades, átributos y relaciones que
se usarán para construir un modelo de datos, pueden empezar por entender cabalmente qué tipos de datos hay en una
organización, cómo se usan los datos y qué marcos de tiempo se usan. Pero, por sí mismos, estos datos e información
no dan el panorama requerido de todo el negocio. Desde el punto de üsta de una base de datos, el conjunto de datos
tiene sentido sólo cuando refleja debidamente reglas de negocios. Una regla de negocios es una descripción bre-
ve, precisa y no ambigua de una política, procedimiento o principio dentro de una organización específica. En cierto
sentido, las ieglas de negocios tienen nombre erróneo, ya que se aplican a cualquier organización, grande o pequeña:
un negocio, una unidad del gobierno, un grupo religioso, un laboratorio de investigación, etc. que guarde y utilize datos
pará genetar información.

Las reglas de negocios, derivadas de una descripción detaliada de las operaciones de una organización, ayudan a crear
y hacer cumplir acciones dentro del ambiente de esa organización. Las reglas de negocios deben darse por escrito y
actualizarse para reflejar cualquier cambio en el ambiente operacional de la organización.

Las reglas de negocios debidamente escritas se usan para definir entidades, atributos, relaciones y restricciones. Cada
vezque se vean enunciados de relación, como "un agenie puede atender a varios clientes y cáda cliente puede ser aten-
dido por un solo agente", se observan reglas de negocios aplicadas. Se verá la aplicación de reglas de negocios en todo
este libro, en especial en los capítulos dedicados al modelado de datos y diseño de bases de datos.
Para ser eficientes, las reglas de negocios deben ser fáciles de entender y ampliamente diseminadas, para asegurarse
que toda persona dentro de la organización comparta una interpretación común de las reglas. Las reglas de negocios
describen, en lenguaje sencillo, las características principales y distintivas de los datos como los ue la compañía. Ejem-
plos de reglas de negocios son los siguientes:
. Un cliente puede generar muchas facturas.
o Una factura es generada por un solo cliente.
. Una sesión de capacitación no puede ser programada para menos de 1,0 o para más de 30 empleados.
)
Nótese que esas reglas de hegocios establecen entidades, relaciones y restricciones. Por ejemplo, las primeras dos reglas
r de negocios establecen dos entidades (CUENTES y FACTURA) y una relación 1:M entre esas dos entidades. I¡
tercera
l
regla de negocios establece una restricción (no menos de 10 y no.más de 30 personas), dos entidades (EMPLEADO y
CAPACITACIÓ$ y una relación entre EMPLEO y CAPACITACIÓN.

ñDEscuBRrMrENTo DE Lr\s REGLA' DE NEGocros

Las principales fuentes de reglas de negocios son los gerentes de compañías, directores de políticas, gerentes de depar-
tamento y documentación escrita como los procedimientos y normas de una compañía y los manuales de operaciones.
Uná fuente más rápida y directa de reglas de negocios son las entreüstas directas con usuarios finales. Desafortunada-
mente, debido a que las percepciones difieren, los usuarios finales son a veces una fuente menos confiable cuando se
trata de especificar reglas de negocios. Por ejemplo, el mecánico de un departamento de mantenimiento podría pensar
que cualquier mecánico puede iniciar un procedimiento de mantenimiento, cuando en realidad sólo mecánicos con
autorización de inspección pueden hacerlo. Esta distinción podría ser triüal, pero puede tener consecuencias legales
importantes. Aun cuando los usuarios finales son aportadores de gran importancia para el desarrollo de reglas de ne-
gocios, do buenos resultodos uerificar las percepciones del usuorio final, con mucha frecuencia, las entrevistas con
varias personas que realizan el mismo trabajo dan percepciones muy diferentes de cuáles son los componentas del tra-
bajo. Si bien este descubrimiento puede apuntar a "problemas de administración", ese diagnóstico general no ayuda al
diseñador de una base de datos, cuyo trabajo es reconciliar esas diferencias y verificar los resultados de la reconciliación
para asegurar que las reglas de negocios sean apropiadas y precisas.

El proceso de identificar y documentar reglas de negocios es esencial para el diseño de bases de datos, por varias ra-
zones:
". Ayudan a estandarizar la üsión de datos de la compañía.
Pueden ser una herramienta de comunicación entre usuarios y diseñadores.
. Permiten que el diseñador entienda la naturaleza, función y propósito de los datos.
) " Permiten que el diseñador entienda los procesos de negocios.
? " Permiten que el diseñador desarrolle restricciones y reglas apropiadas de paiticipación de relaciones y pueda
t crear un modelo de datos apropiado.
.5

;- Desde luego, no todas las reglas de negocios se podrán modelar. Por ejemplo, una regla de negocios que especifique
)
que "ningún piloto podrá volar más de 10 horas dentro de cualquier periodo de 24 horas" no se puede modelar. No
obstante, el software de aplicación puede hacer cumplir esa regla.

WcoNvERsróN DE REGLAS DE NEcocros EN coMpoNENTEs DE MoDELo DE DATos

Las reglas de negocios preparan el escenario para la correcta identificación de entidades, atributos, relaciones y res-
tricciones. En la práctica, se usan nombres para identificar objetos. Si el ambiente de negocios desea dar seguimiento
a objetos, habrá reglas de negocios específicas para ellos. Como regla general, un sustantivo en una regla de negocios
lo convertirá en entidad en e[ modelo y un verbo (activo o pasivo) que asocie sustantivos lo convertirá en una relación
entre entidades. Por ejemplo, la regla de negocios "un cliente puede generar muchas factums" contiene dos sustantivos
(clientey facturas) y un verbo (generar) que los asocia. De esta regla de negocios se puede deducir que:
o Cliente y factura son objetos de interés para e[ ambiente y deben estar representados por sus respectivas
entidades.
. Hay una relación "generar" entre cliente y factura.
:. ::

Para identificar en forma correcta el tipo de relación se deben considerar que las relaciones son bidireccionales, es decir,
son para ambas direcciones. Por ejemplo, la regla de negocios "un cliente puede generar muchas facturas" es comple-
mentada por la regla "una factura es generada sólo por un cliente". En este caso, la relación es uno a muchos (1'M). El
cliente es el lado del "1" y la factura es el lado de "muchos".

Como regla general, para identificar correctamente el iipo de relación, deben hacerse dos preguntas:
. ¿Cuántas instancias de B están relacionadas con una instancia de A?
o ¿Cuántas instancias de A están relacionadas con una instancia de B?
Por ejemplo, se puede evaluar la relación entre esfudiante y grupo si se hacen dos preguntas:
o ¿En cuántos grupos puede inscribirse un estudiante? Respuesta: en muchos grupos.
o ¿Cuántos estudiantes pueden inscribirse en una clase? Respuesta: muchos estudiantes.
Por tan{o, la relación entre estudiante y grupo es muchos a muchos (M:N). EI lector tendrá muchas oportunidades para
determinar las relaciones entre entidades a medida que avance en el estudio de este'libro y pronto el proceso pasará a
ser natural.

EEI oo* *or"*. o "o*rr*",o^rt


Durante la conversión de reglas de negocios a componentes de modelo de datos el usuario identifica entidades, atribu-
tos, relaciones y restricciones. Este proceso de identificación incluye dar nombre al objeto en una forma que haga que
éste sea único y distinguible de otros objetos del dominio del problema. En consecuencia, es importante prestar especial
atención a cómo dar nombre a objetos que se descubran.

Los nombres de entidad deben ser descriptivos de ios objetos en el ambiente de negocios y debe emplearse terminologla
que sea conocida por los usuarios. Un nombre de atributo también debe ser descriptivo de los datos representados por
ese atributo. Asimismo es una buena práctica aplicar un prefijo al nombre de un atributo, con el nombre de la entidad
(o una abreviatura del nombre de la entidad) en la que se presente. Por ejemplo, en la entidad CUSTOMER, el límite de
crédito del cliente puede recibir el nombre de CUS_CREDIT_UMIT. El prefijo CUS indica que el atributo es descriptivo
de la entidad CUSTOMER, en tanto que CREDIT-LIMIT hace fácil reconocer los datos que estarán contenidos en el
atributo. Esto se hará cada vezmás importante en capíhrlos posteriores cuando discutamos la necesidad de usar atribu-
tos comunes para especificar relaciones entre entidades. El uso de una convención apropiada para dar nombres va a
mejorar la capacidad del modelo de datos para facilitar la comunicación entre el diseñador, el programador de aplicación
y el usuario final. De hecho, una correcta convención para dar nombre_s puede recorrer un largo camino para hacer que
el modelo se documente a sí mismo.

La búsqueda de una mejor administración de datos ha llevado a varios modelos que tratan de resolver los defectos criti-
cos del sistema de archivos. Estos modelos representan escuelas de pensamiento en torno a qué es una base de datos,
qué debe hace¡ los tipos de estructuras que debe emplea¡ así como la tecnología que debería usarse para implementar
estas estructuras. Quizás en forma confusa, estos modelos se denominan modelos de datos, al igual que los modelos de
datos gráficos que hemos estado esfudiando. Esta sección da un repaso acerca de los principales modelos de datos en
orden aproximadamente cronológico. El lector descubrirá que muchos de los "nuevos" conceptos y estructuras de bases
de datos tienen un parecido sorprendente con algunos de los "üejos" conceptos y estructuras de modelos de datos. La
tabla 2.1 sigue la evolución de los principales modelos de datos.

:HI

. ,, :1,..:
.:,:

,,.''.$

..
.te
fF

. :;::.::::

: . .::t:.it

..,1¡.: :1i;:!

1:,r.1'r:ri:ir¡:

,::" : - r;

. :,. ,
-.r- ¡i F.^É ii- .41
¡11-{r,i{-qiLtrH

ffi r.roo-.o" r=*Á*qr,"o, o.


^.o
El r¡¡odelo jerárquico se desarrolló en la década de 7960 para manejar grandes cantidades de datos para com-
plejos proyectos de manufactura, como el cohete Apolo.que aterrizó en la Luna en 7969. Su estructura lógica básica
está representada por un árbol invertido. La estrucfura jerárquica contiene niveles, o segmentos. Un segmento es
el equivalente de un tipo de registro de un sistema de archivos. Dentro de una jerarquía, se percibe una capa más alta
como el padre del segmento directamente bajo ella, que se denomina hijo. El modelo jerárquico describe un conjunto de
relaciones de uno a muchos (1:M) entre un padre y sus segmentos hijos. (Cada padre puede tener muchos hijos, pero
cada hijo tiene sólo un padre.)

El r¡¡odelo de red fue creado para representar complejas relaciones de datos en forma más efectiva que el modelo
jerárquico, para mejorar la operación de una base de datos y para imponer un estándar de base de datos. En el mo-
delo de red, el usuario percibe la base de datos de red como un conjunto de registros en relaciones 1:M, pero, a diferen-
cia del modelo jerárquico, el modelo de red permite que un registro tenga más de un padre. En tanto que el modelo de
base de datos de red generalmente no se usa en la actualidad, las definiciones de conceptos estándar de bases de daios
que emergieron con el modelo de red iodavía se usan en modelos modernos de datos. Algunos conceptos importan-
tes que se definieron son'
n El esquer¡ta, que es la organización conceptual de toda la base de datos según la ve el administrador.
Elsubesquema, que define la parte de la base de datos "vista" por los programas de aplicación que en realidad
producen la información deseada a partir de los datos contenidos dentro de la base de datos.
Un lenguaie de adrninistración de datos (DMt), qge define el ambiente en el que los datos se pueden
administrar y para trabajar con los datos en la base de datos.
Un esquema de lenguaje de deñnición de datos (DDL), que hace posible que el administrador de una rrLiT

base de datos defina los componentes del esquema. ,li,E


..,.t :::l
.,
'.,,.
1,.

,.:.,:
:t'
l
.i.:l
A medida que crecieron las necesidades de información y se requirió de refinadas bases de datos y aplicaciones, el : ':,. l.
'i,..1
.,i,.1i:: I
:i't.r::L
modelo de red se hizo demasiado engoffoso. La falta de capacidad de consulta ad hoc puso una fuerte presión sobre ..

los programadores pam generar el código requerido para producir incluso los informes más sencillos. Y aun cuando
las bases de datos existentes brindaban una limitada independencia de datos, cualquier cambio estruchrral en la base de
datos podía hacer estragos en todos los programas de aplicación que sacaban datos de la base de datos. Debido a las
desventajas, los modelos jerárquico y de red, fueron susütuidos en gran parte por el modelo de datos relacional en la
. i...i.'
1..: .1 F
,i i,:li
r.i.1::1.

década de 1980. .':t+l


:,1:;: l
j:ill'
.i'.i.I
.:tr'l
;:,:;,1

"i. I

!f,f,! EL MoDELo RELA.T.NAL rtl


.,tl
'j,, I

EI modelo relacional fue introducido en la década de 7970 por E. F. Codd (de IBM) en su destacado artículo cien- ,ij "l

tífico "A Relational Model of Data for Large Shared Databanks" (Communications of the ACM, junio de 1970, pp. ,..i
.:..:1
.t..:

377-38n. El modelo relacional representó un importante avance pará usuarios y diseñadores. Para usar una analogía, i.:tl':
i,:,:r

el modelo relacional produjo una base de datos de "transmisión automática" para sustituir las bases de datos de "trans-
misión estándar" que le precedieron Su sencillez conceptual preparó el terreno para una genuina revolución en las
bases de datos.

El modelo de bases de datos relacionales presentado en este capítulo es una introducción y un repaso. Un estu-
dio más detallado está en el capítulo 3, El modelo de bases de datoc relacional. De hecho, el mode-
lo relacional es tan importante que servirá como base para exposiciones en casi todos los capífulos siguientes.
E

v
La base del modelo relacional es un concepto matemático conocido como relación. Para eütar la complejidad de Ia I
teoría matemática abstracta, se puede considerar una relación (a veces llamada tabla) como una matriz compuesta I
de filas y columnas que se intersecan. Cada fila en una relación se llama tupla. Cada columna representa un atributo. I
El modelo relacional también describe un preciso conjunto de construcciones para manipulación de datos basado en t
conceptos matemáticos avanzados. I

En 1970, la obra de Codd fue considerada ingeniosa pero impráctica. La sencillez conceptual del modelo relacional fue
comprada a expensas de gastos generales de computadora; las computadoras en aquel tiempo carecían de potencia
para poner en práctica el modelo relacional. Por fortuna, la potencia de computadoras creció en forma exponencial, al
igual que la eficiencia de los sistemas operativos. Todavía mejor, el costo de computadoras disminuyó con gran rapidez
a medida que crecía su potencia. En la actualidad, hasta las computadoras personales, que valen sólo una parte de lo
que costaban sus antecesoras mainframes, pueden ejecutar un complejo softu¿are de bases de datos relacionales como
Oracle, DB2, Microsoft SQL Server, MySQL y otros tipos de sofhvare relacional de mainframes.

El modelo relacional de datos se implementa por medio de un complejo sistema de administración de base de
datos relacional (BDBMS, por sus siglas en inglés). El RDBMS realiza las mismas funciones básicas de los
sistemas DBMS jerárquico y de red, además de una amplia variedad de otras funciones que hacen que el modelo de
datos relacional sea más fácil de entender e implementar.

Es discutible que la ventaja más importante del RDBMS sea su capacidad para ocultar al usuario las complejidades del
modelo relacional. El RDBMS maneja todos los detalles físicos, en tanto que el usuario ve la base de datos relacional
como un conjunto de tablas en las que se guardan datos. El usuario puede manipular y consultar los datos en una forma
que parece intuitiva y lógica.

Las tablas están relacionadas entre sí al compartir un atributo común (valor en una columna). Por ejemplo, la tabla
CUSTOMER (cliente) de la figura 2.7 podria contener el número de un agente de ventas que también está contenido
en la tabla AGENT (agente).
ad FBfrqJffiA
ry*
ffi6 lfi

2n
,.
na N o nn b re'd e, tab.l a:,ACE§T, (p r[m-erós rc is. atr! but6á¡. -,

el lc¿e
;l¡l-l

)re
Co
de
t^^
id5
la

:{l-
'p.
ía,
']s-
,as

.,wfr
:iiw

El vínculo común entre las tablas CUSTOMER y AGENT hace posible formar parejas eotre el cliente y su agente de
ventas, aun cuando los datos del cliente estén guardados en una tabla y los del representante de ventas en otra. Por
1a ejemplo, fácilmente se puede determinar que el agente del cliente Dunne es AIex Alby porque para el cliente Dunne,
-+^
-Ld
AGENT-CODE de la tabla CUSTOMER es 501, que coincide con AGENT-CODE de la tabla AGENT para Alex Alby.
:C. Aun cuando las tablas son independientes entre sí, con toda facilidad se pueden asociar los datos entre ellas. El modelo
.lO relacional tiene un nivel mínimo de redundancia, ya que es controlado para eliminar casi todas las redundancias que por
Io común se encuentran en los sistemas de archivos.

te
r.'ia El tipo de relación (1 :1, 1:M o M:N) a veces se presenia en
FEGUffi,&
al ry9 un esquema relacional, un ejemplo se ve en la figura 2.2.
Mek

:ZZ Un dñagraffiB@ re§aeÉ638?aÉ es una representación de las


io entidades de la base de datos relacional, los atributos den-
lo :
tro de esas entidades y las relaciones entre esas entidades.

r:i
AGEP,¡T-COüE En la figura 2.2, el diagrama relacional muestra los cam-
AGEt-t _IFIAME CU§-LI{AME
..tu pos de enlace (en este caso, AGENT*CODE) V el tipo de
A"GEI"II-FNAME fus FF.IAME

)S AGEÍ{LIP,IITIAL TU5-IhTIIIAI relación, 1:M. Microsoft Access, la aplicación de base


1

\o
AGEI{T-AR.EA{GDE CU§-AREACOÜE de datos empleada para generar la figura 2.2, emplea
AGEruT_PHTJNE
AGEzuT-ADDRE§5
CU5-PHüruE
fT.}5-If{5URE-TYPE
el símbolo ". (infinito) para indicar el lado "muchos". En
AGENT-ilIY f U5_II*§tlRE_Afr4T este ejemplo, CUSTCMER representa el lado "muchos"
:', el
AGEÍ{L5TATE {U5-RENE$J-üATE porque un ACENT puede tener muchos CUSTCMERs.
A'GEI'¡T-EF AGEITI-{üDE
.al AGEP'IT-DAT[-HIREB
AGENT representa el lado " 1" porque cada CUSTOMER
-:la AGE['IT_YTD_PAY tiene sólo un AGENT.
AGEf.¡T_ffD_Ffl-
ACE[\¡T_YTD_FICA
AGEhn_rtD-51!
,ia AGEI''{T_DEF

lo

Potrebbero piacerti anche