Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache Wiki <wikidiffs@apache.org>
To: Apache Wiki <wikidiffs@apache.org>
Date: Sat, 11 Dec 2010 18:48:04 -0000
Message-ID: <20101211184804.83328.3471@eosnew.apache.org>
Subject: 
 =?utf-8?q?=5BCassandra_Wiki=5D_Trivial_Update_of_=22ThomasBoose/EERD_mode?=
 =?utf-8?q?l_components_to_Cassandra_Column_family=27s=22_by_ThomasBoose?=

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 h=
as been changed by ThomasBoose.
http://wiki.apache.org/cassandra/ThomasBoose/EERD%20model%20components%20to=
%20Cassandra%20Column%20family%27s?action=3Ddiff&rev1=3D12&rev2=3D13

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

  #language en
  =3D A way to implement (E)ERD components in Cassandra =3D
  =3D=3D Intro =3D=3D
- This page describes model tranformations from EERD concepts into Cassandr=
a ColumnFamily concepts. All input is welcome.
+ This page describes model tranformations from (E)ERD concepts into Cassan=
dra ColumnFamily concepts. All input is welcome.
  =

  =3D=3D DBMS layer =3D=3D
- At several spots in this document you wil find suggestions to implement t=
rivial DBMS functionality by hand. At this stage, I would suggest to progra=
mmers to implement at least 4 tiers when using Cassandra as a backend serve=
r. One would be the database layer by cassandra itself, One would be a tier=
 implementing DBMS rules, another for business rules finishing with an appl=
ication tier.
+ At several spots in this document you wil find suggestions to implement t=
rivial DBMS functionality by hand. At this stage, I would suggest to progra=
mmers to implement at least 4 tiers when using Cassandra as a backend serve=
r. One would be the database layer by Cassandra itself, One would be a tier=
 implementing DBMS rules, another for business rules finishing with an appl=
ication tier.
  =

  In this DBMS tier functions should be available for keeping data consiste=
nd based on datarules and it would throw exceptions when indexes are change=
d or orders are given to delete key's agains DBMS rules.
  =

@@ -86, +86 @@

  =3D=3D=3D 1 to Many =3D=3D=3D
  In one to many relationships we add the key from the "one" side foreign t=
o the "many" side. So if we're moddeling students studing at only one schoo=
l-unit at a time we would add the unit's key to the student as foreign. Con=
sidering 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. Cosidder=
ing the fact that this kind of relation is very common one could best creat=
e 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_S=
tudent ColumnFamily is called "school-unit". In a cassandra database this i=
s not sufficient to retrieve all student within this unit. One could find a=
nswers to questions like these but it would require quite a lot of processi=
ng power. If a ColumnFamily, the cf_School_unit family in this case, has on=
ly 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 i=
n future releases of you system and therefore sugest that you'de provide se=
perate 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_S=
tudent ColumnFamily is called "school-unit". In a Cassandra database this i=
s not sufficient to retrieve all student within this unit. One could find a=
nswers to questions like these but it would require quite a lot of processi=
ng power. If a ColumnFamily, the cf_School_unit family in this case, has on=
ly 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 i=
n future releases of you system and therefore sugest that you'de provide se=
perate ColumnFamily's for each one to many relationship that you model.
  =

  This would leed to three ColumnFamily's
  ||||||||<tablewidth=3D"400px"style=3D"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 u=
nit.
  =

- If a one to many relationship contains itself attributes, which is perfec=
tly 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 perfec=
tly acceptable in a (E)ERD model. One could be inspired to use SuperColumns=
. Cassandra SuperColumns are column that can contain columns themself.
  =

  =3D=3D=3D Many to Many =3D=3D=3D
  {{http://boose.nl/images/manytomany.jpeg}}
  =

- Lets look at a very basic part of an EERD model. The power of chen ERD mo=
dels is that a lot of implicit information can be left out. Models should b=
e simplefied versions of their reallife counterparts. No DBMS, relational n=
or 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 Relation=
al systems we would create a new table that would represent the relationshi=
p. This table would consist of both the key's (foreign keys) of the adjacce=
nt entities, being primairy togetter, supplemented with its own attributes.
  =

- As it is perfectly valid in a relational database to have a key value com=
posed of several columns, in cassandra there is only one key per ColumnFami=
ly. 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 w=
hether or not maybe in the future a new relation will popup to another enti=
ty 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 com=
posed of several columns, in Cassandra there is only one key per ColumnFami=
ly. 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 w=
hether or not maybe in the future a new relation will popup to another enti=
ty 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=3D"text-align: center;">CF_Order ''' ''' ||