cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cassandra Wiki] Trivial Update of "ThomasBoose/EERD model components to Cassandra Column family's" by ThomasBoose
Date Sat, 11 Dec 2010 18:48:04 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.

The "ThomasBoose/EERD model components to Cassandra Column family's" page has been changed
by ThomasBoose.
http://wiki.apache.org/cassandra/ThomasBoose/EERD%20model%20components%20to%20Cassandra%20Column%20family%27s?action=diff&rev1=12&rev2=13

--------------------------------------------------

  #language en
  = A way to implement (E)ERD components in Cassandra =
  == Intro ==
- This page describes model tranformations from EERD concepts into Cassandra ColumnFamily
concepts. All input is welcome.
+ This page describes model tranformations from (E)ERD concepts into Cassandra ColumnFamily
concepts. All input is welcome.
  
  == DBMS layer ==
- At several spots in this document you wil find suggestions to implement trivial DBMS functionality
by hand. At this stage, I would suggest to programmers to implement at least 4 tiers when
using Cassandra as a backend server. One would be the database layer by cassandra itself,
One would be a tier implementing DBMS rules, another for business rules finishing with an
application tier.
+ At several spots in this document you wil find suggestions to implement trivial DBMS functionality
by hand. At this stage, I would suggest to programmers to implement at least 4 tiers when
using Cassandra as a backend server. One would be the database layer by Cassandra itself,
One would be a tier implementing DBMS rules, another for business rules finishing with an
application tier.
  
  In this DBMS tier functions should be available for keeping data consistend based on datarules
and it would throw exceptions when indexes are changed or orders are given to delete key's
agains DBMS rules.
  
@@ -86, +86 @@

  === 1 to Many ===
  In one to many relationships we add the key from the "one" side foreign to the "many" side.
So if we're moddeling students studing at only one school-unit at a time we would add the
unit's key to the student as foreign. Considering that no foreign key logic is provided you
will have to write your own code to enforce consistancy in unit's existing, when the unit
attribute of a student is set, and defining behaviour when deleting a unit. Cosiddering the
fact that this kind of relation is very common one could best create the logic for this at
a seperate DBMS tier.
  
- Every student has only one school-unit so we enforce one static name of a column that will
reference this unit. for instance this column in the cf_Student ColumnFamily is called "school-unit".
In a cassandra database this is not sufficient to retrieve all student within this unit. One
could find answers to questions like these but it would require quite a lot of processing
power. If a ColumnFamily, the cf_School_unit family in this case, has only one of these relations,
then one could chose to add all student keys to that ColumnFamily it self. I would not count
on this situation persisting in future releases of you system and therefore sugest that you'de
provide seperate ColumnFamily's for each one to many relationship that you model.
+ Every student has only one school-unit so we enforce one static name of a column that will
reference this unit. for instance this column in the cf_Student ColumnFamily is called "school-unit".
In a Cassandra database this is not sufficient to retrieve all student within this unit. One
could find answers to questions like these but it would require quite a lot of processing
power. If a ColumnFamily, the cf_School_unit family in this case, has only one of these relations,
then one could chose to add all student keys to that ColumnFamily it self. I would not count
on this situation persisting in future releases of you system and therefore sugest that you'de
provide seperate ColumnFamily's for each one to many relationship that you model.
  
  This would leed to three ColumnFamily's
  ||||||||<tablewidth="400px"style="text-align: center;">CF_Student ''' ''' ||
@@ -110, +110 @@

  
  No value's are actualy stored in the columns indicating de studentnumbers. These columns
only exist to indicate which students are present in this unit.
  
- If a one to many relationship contains itself attributes, which is perfectly acceptable
in a EERD model. One could be inspired to use SuperColumns. Cassandra SuperColumns are column
that can contain columns themself.
+ If a one to many relationship contains itself attributes, which is perfectly acceptable
in a (E)ERD model. One could be inspired to use SuperColumns. Cassandra SuperColumns are column
that can contain columns themself.
  
  === Many to Many ===
  {{http://boose.nl/images/manytomany.jpeg}}
  
- Lets look at a very basic part of an EERD model. The power of chen ERD models is that a
lot of implicit information can be left out. Models should be simplefied versions of their
reallife counterparts. No DBMS, relational nor NoSQL, can by itself implement many to many
relationships. In Relational systems we would create a new table that would represent the
relationship. This table would consist of both the key's (foreign keys) of the adjaccent entities,
being primairy togetter, supplemented with its own attributes.
+ Lets look at a very basic part of an (E)ERD model. The power of chen ERD models is that
a lot of implicit information can be left out. Models should be simplefied versions of their
reallife counterparts. No DBMS, relational nor NoSQL, can by itself implement many to many
relationships. In Relational systems we would create a new table that would represent the
relationship. This table would consist of both the key's (foreign keys) of the adjaccent entities,
being primairy togetter, supplemented with its own attributes.
  
- As it is perfectly valid in a relational database to have a key value composed of several
columns, in cassandra there is only one key per ColumnFamily. I did already discuss the need
 to create seperate  ColumnFamily's for one to many relationships given the fact that you
can never tell for sure whether or not maybe in the future a new relation will popup to another
entity sharing the same keyvalues. This means that we will need 5 ColumnFamily's to implement
the model above:
+ As it is perfectly valid in a relational database to have a key value composed of several
columns, in Cassandra there is only one key per ColumnFamily. I did already discuss the need
 to create seperate  ColumnFamily's for one to many relationships given the fact that you
can never tell for sure whether or not maybe in the future a new relation will popup to another
entity sharing the same keyvalues. This means that we will need 5 ColumnFamily's to implement
the model above:
  
  CF_Order is a straight forward  ColumnFamily, Modeled after the design
  ||||||||<style="text-align: center;">CF_Order ''' ''' ||

Mime
View raw message