11. Datos Notebook { Id = 1234 Marca = Lenovo Modelo = T500 Disco { Tipo = SSD Tamaño { Unidad = 128 Medida = GB } } } Persona { Id = 5678 Nombre = Camila Padre = Nicolas } Persona { Id = 9123 Nombre = Nicolas Cuadro = Peñarol }
Estos distintos modelos en donde mas se diferencian es en como tratan las relaciones entre las entidades. En los dos extremos tenemos: el Modelo Relacional por un lado, que define los siguientes criterios: No hay diferencia entre las Entidades y las Relaciones entre entidades, todo se representa como tablas. La relación entre las entidades se representa de forma implícita, por los atributos que tienen en común. Así, por ejemplo, la forma de definir que la Factura tiene una relación n-1 con el Cliente es poner la PK de Cliente en la tabla de Factura. en el otro extremo, en el Modelo de Datos Orientado a Objetos los criterios son: Cada objeto de una Entidad tiene un identificador único (normalmente llamado Object Id). Las relaciones entre los objetos se realiza explícitamente mediante los Object Id. De esta manera, una Factura debe tener el Object Id del Cliente correspondiente y el Cliente debe mantener una lista de sus Facturas.
Supongamos que se quiere almacenar en una base de datos relacional archivos XML. La solución más simple consiste en tener una sola tabla del tipo:File { FileId* FileNameFileContent // aquí se almacena el contenido del archivo XML (normalmente como un string) }Si bien este modelo es extremadamente sencillo, tiene una serie de problemas. Algunos de ellos: Se está asumiendo que el contenido de cada File no tiene links a otros Files pero, si lo que se quiere es poder registrar las relaciones entre los datos, este modelo lo hace casi imposible. Los mecanismos de búsqueda por algunos valores particulares solo se pueden hacer vía algún mecanismo de full textsearch. Esto dificulta la implementación de criterios de integridad (no borrar un elemento si está siendo referenciado en otro lugar, etc.).
