Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

An Introduction to Database Models Expand / Collapse
Author
Message
Posted Saturday, February 07, 2004 5:46 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Tuesday, August 13, 2013 1:18 AM
Points: 5,956, Visits: 285
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/fk

--
Frank Kalis
Microsoft SQL Server MVP
Webmaster:
http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/
Post #99218
Posted Thursday, February 12, 2004 1:58 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 1:48 AM
Points: 2,864, Visits: 1,704

Interesting!

I thought that hierachal databases were making a come back for very large databases because of their performance advantages.

Are XML databases hierachal?

Do you know if there are there any OO databases on the market at present?

 



LinkedIn Profile
Newbie on www.simple-talk.com
Post #99972
Posted Thursday, February 12, 2004 6:16 AM
UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Saturday, February 28, 2009 6:51 AM
Points: 1,489, Visits: 7

I don't want to make this into any kind of flame war or anything, but I must address a couple of points here. I do not know what Frank Kalis thinks about the models described as the article is mainly a description of them, so these comments are not made to say he is wrong, they are written to address some points in the article that I think can be wrongly understood or accepted by some readers.

As said in the article, the relational model clearly distinguishes the logical desgin from the physical. The relational model is all about the logical and nothing about the physical part. Therefore it is impossible to say that any other database management model has better or worse performance, because performance is based on the physical design solely. This is in fact the greatest advantage of the relational model, apart from it's theoretical foundation (which no other model has, or at least not as clear), that the decisions you make on logical design issues will not affect the physical design. It is up to the RDBMS to decide how the logical design you create is best handled physically.

For the same reasons, it is also not correct to say that "[the] most significant [of] several weaknesses of the relational model ... is the inability to handle BLOB's." In the relational model, a relation has one or more attributes that are defined as being of specific domains. There is nothing that says that a domain can not be a BLOB or any other type of data. For a complete discussion and description of this see for instance the paper 'What first normal form really means' by C.J Date. Any flaw in handling these domains is purely a fault of the DBMS, not the relational model. Here is a nice quote from the above mentioned paper:

A proper object/relational system is just a relational system with proper type support ... --which simply means it's a proper relational system, no more and no less.

Regarding the OO 'model':

"The developer of such a system is responsible for implementing methods and properties to handle the data in the database from within his object-oriented application. There is no longer a strict distinction between application and database."

I would say that there is no longer a database, or at least not a DBMS. The reason to have a DBMS is precisely to have a centralized system for controlling the database, especially the integrity of it, so that the application developers do not need to (or must not even) know and control how to access the data. Using this approach we regress back to 40 years ago and leave all the work to each application, and we can only hope that each application takes care of what needs to be taken care of. Also, this means that each database you create is heavily linked to a specific application, if you want some other application to access the same data in just a slightly different way you probably need to either make changes to the first application or make the integrity constraints even more complex than what is already necessary using this 'model'. You'll notice that I put the word model in quotes when discussing the OO 'model'. This is because I do not think it is a complete data model, unlike the relational model. See for instance 'Something to call one's own'.

Finally, I have to disagree with the conclusion that "there (still) is a world outside the relational model, which can be pretty exciting to discover". All of these other so-called models are either old ones that were replaced by the relational model because of the flaws they had, or regressions to these old models by re-inventing them and calling them something different. The relational model is based on set theory and predicate order logic, anything trying to replace the relational model must also be a replacement for these theories several centuries old and proven.

With all this said, I still find this a good and interesting article as it brings up the discussion of points like these, and I kind of think that is one of the reasons why Frank wrote it.





--
Chris Hedgate http://www.hedgate.net/
Contributor to the Best of SQL Server Central volumes
Articles: http://www.sqlservercentral.com/columnists/chedgate/
Post #100000
Posted Thursday, February 12, 2004 6:26 AM
UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Saturday, February 28, 2009 6:51 AM
Points: 1,489, Visits: 7

As I explained in my other posting (in response to the article itself), any lack of performance is not a fault of the relational model but of the implementation of it (i.e. SQL). However, if we do compare SQL DBMSs to hierarchical DBMSs and do find that the latter generally has higher performance (I have no idea if this is true, and I highly doubt it), remember that this performance would come at a loss of integrity. And without the integrity of the database protected, what good is high performance? Also, once again the hierarchical model had several huge problems incl. the lack of separation between the logical and physical design. This leads to problems like the ones I described above regarding OO databases plus the fact that the user needs to know the physical access paths for the data, and is of course one of the reasons why the relational model replaced it 30 years ago. The same goes for XML which as you probably suspect is hierarchical, yes.





--
Chris Hedgate http://www.hedgate.net/
Contributor to the Best of SQL Server Central volumes
Articles: http://www.sqlservercentral.com/columnists/chedgate/
Post #100003
Posted Thursday, February 12, 2004 6:59 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 2:31 PM
Points: 292, Visits: 254

I would like to add a little bit of personal opionion on the OODB topic.

The concept of an Object-Oriented Database just seems wacky  to me. Objects imply action. If you're thinking in terms of Object-Oriented programming, the really important stuff is the behavior of the objects. The data storage is irrelevant. In reality, a relational DBMS is the perfect data store for an OO system. There isn't anything the relational model can not handle for OO data storage. The only thing it can not handle is the behavior/methods/operations/pick-your-term. And by all rights it has no business performing actions on the data since that is clearly business logic.

I worked with another DBA that did some considerable research on OODB's and his conclusion (Which I expected it to be in the first place) was that they are immature constructs for developers that are too lazy to build a code generation engine to develop the code between the data and the business logic. (Quick plig for my favorite code generator - CodeSmith)



Bryant E. Byrd, BSSE MCDBA MCAD
Business Intelligence Administrator
MSBI Administration Blog
Post #100014
Posted Thursday, February 12, 2004 7:51 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Friday, March 21, 2014 7:45 AM
Points: 1,138, Visits: 698

An article by C.J. Date on data models, what is a data model, and (more importantly?) what's not:

http://www.dbdebunk.com/page/page/622923.htm



--
Adam Machanic
SQL Server MVP
SQLblog.com: THE SQL Server Blog Spot on the Web
Post #100030
Posted Thursday, February 12, 2004 9:06 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, September 06, 2005 10:53 AM
Points: 107, Visits: 1

There isn't anything the relational model can not handle for OO data storage. The only thing it can not handle is the behavior/methods/operations/pick-your-term. And by all rights it has no business performing actions on the data since that is clearly business logic.

I'm very new to database-isms,  but I was making my database a very active one (ie, code the business rules into the database as triggers, stored procedures, and tasks; for example, when an alarm gets inserted into the db, a trigger fires off and if the alarm matches a mask in a different table, the database would email me using sqlmail).

Your comment makes me wonder if that is really the way I should do it, so here are my newbie questions:

  1. Why separate the business logic into another compartment?  Where/how would it run?
  2. Is there a way to pass an event from the db to an application (db says "New Data in table Foo.", instead of the app pulling a dataset every few minutes and detecting changes -- is there a way to do this w/o pulling a whole dataset)?

We're planning on having some events that run every minute, others that run daily, and some others (like the alarms above) that run based on row(s) modified in the table.

Any reason my db should be quiet place of solitude vs a "Active Do-All Buzzing Database"?

TIA,
Thor




Post #100052
Posted Thursday, February 12, 2004 9:20 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 2:31 PM
Points: 292, Visits: 254

Triggers vs. Polling

This is a trade-off decision.

Is the trigger load greater than the load would be if you polled every few minutes? If the database is getting hammered then the trigger load is likely higher than would be expected for polling at intervals.

How "real-time" do the alerts need to be? If you can wait five minutes or more then polling looks a little more attractive.

What is the project schedule like?  Seriously though, if you can take time out for quality, you can theoretically eliminate both. I haven't doen this yet but I have been thinking about it. If your application is using .NET or a similarly capable platform (Java should be able to handle it along with many other OO platforms) you could write a data access layer using a single-call type methodology where there is only one set of the classes instantiated at a time and all calls to update the DB are handled through this set of classes. That way you can perform the update and send a notification via event and/or delegate to any other classes that are tied to it. It sounds pretty complex but once you worked out the details I bet you could come up with a code generator that would build the classes for you (See my earlier post).

 



Bryant E. Byrd, BSSE MCDBA MCAD
Business Intelligence Administrator
MSBI Administration Blog
Post #100056
Posted Thursday, February 12, 2004 9:24 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Friday, March 21, 2014 7:45 AM
Points: 1,138, Visits: 698

Thor:

There is a fine line between "business rules" (e.g. constraints) and "business logic" (e.g. if user enters something in this field, pop up this message)... It really needs to be determined on a case-by-case and application-by-application basis.  Some apps are, by nature, much more data-driven than others.  However, on the whole I've seen much less dependency on the database for constraints than I think there should be.  One of the primary points of the database is the enforce data integrity, yet most shops prefer to do that all in the application layer and use the database only as a data store.  That, IMO, is a mistake.

As for a way to pass an event from the db to an application, you can look into writing extended stored procedures.  Yet another part of the database that's under-used, IMO!



--
Adam Machanic
SQL Server MVP
SQLblog.com: THE SQL Server Blog Spot on the Web
Post #100059
Posted Thursday, February 12, 2004 9:27 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Friday, March 21, 2014 7:45 AM
Points: 1,138, Visits: 698

Tatsu:

Are you talking about using a queing system to serialize database access?



--
Adam Machanic
SQL Server MVP
SQLblog.com: THE SQL Server Blog Spot on the Web
Post #100060
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse