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=8&rev2=9 -------------------------------------------------- ||Jane ||0555-654321 ||12.000 || + ||||||<tablewidth="400px" tablestyle="text-align: left;"style="text-align: center;">CF_Phone ''' ''' || ||<style="text-align: center;" |2>0555-123456 ||employee ||credit || ||123-12-1234 ||10 || @@ -91, +92 @@ ||Jane ||SE ||Amsterdam || + ||||||<tablewidth="400px" tablestyle="text-align: left;"style="text-align: center;">CF_School_Unit ''' ''' || ||<style="text-align: center;" |2>SE ||name ||loc || ||software engineering ||hsl || + ||||||<tablewidth="400px" tablestyle="text-align: left;"style="text-align: center;">CFK_School_Unit_Student ''' ''' || ||<style="text-align: center;" |2>SE ||123-12-1234 ||321-21-4321 || - || || || + || || || @@ -107, +110 @@ 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. + === 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. + + 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: + + || + ||||||||<style="text-align: center;">CF_Order ''' ''' || + ||<style="text-align: center;" |2>1234 ||order_date ||order_discount ||customer_id || + ||20100808 ||0.4 ||1234 || + ||<style="text-align: center;" |2>4321 ||customer_id ||order_date || || + ||1234 ||20100802 || || + + + || + ||||||||<style="text-align: center;">CF_product ''' ''' || + ||<style="text-align: center;" |2>DSK_SGT_5GB_7200 ||description || image||list_price || + ||5 GB Seagate harddisk || ||130 || + ||<style="text-align: center;" |2>KBD_LGT_WRL_350 ||description ||image ||list_price || + ||Wireless keyboard || ||75|| +
