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=2&rev2=3 -------------------------------------------------- Typicly you'll find three kinds of 1 on 1 relations in a relational model. I will address them one at a time. ==== Equal elements ==== - Sometimes all the elements are part of both collections on either side of the relationship. The reasons these collections are moddeled seperately are most often based on security issues or functional differences. One solution in a Cassandra database would be the same as you would implement such a relation in an RDBMS. Simply by sharing the same key in both ColumnFamily'ss. Inserting a key in one of these ColumnFamily's would insert the same in the other and vise versa. Updating an existing key in either ColumnFamily would not result in any change in the other. Deleting a key from one ColumnFamily will result in deleting the same key in the other family as well, providing this would be allowed. + Sometimes all the elements are part of both collections on either side of the relationship. The reasons these collections are moddeled seperately are most often based on security issues or functional differences. One solution in a Cassandra database would be the same as you would implement such a relation in an RDBMS. Simply by sharing the same key in both ColumnFamily's. Inserting a key in one of these ColumnFamily's would insert the same in the other and vise versa. Updating an existing key in either ColumnFamily would not result in any change in the other. Deleting a key from one ColumnFamily will result in deleting the same key in the other family as well, providing this would be allowed. ''I'm not sure to what detaillevel security rules can apply in a Cassandra database. At least I know that one can creat logins per cluster.'' - If it gets necessary to use different keys for both collections, sometimes it is not up to one designer to select both keys, although the number of element are equal and they are related one on one, in a relational model the designer gets to select either key to insert into the other collection with an unique and foreign key constraint. + If it is necessary to use different keys for both collections, sometimes it is not up to one designer to select both keys, although the number of element are equal and they are related one on one, in a relational model the designer gets to select either key to insert into the other collection with an unique and foreign key constraint. - In Cassandra modeling you are forced to either croslink both key's, So you design both key's foreign in both columnfamily's. Or you create a third columnfamily in which you store both keys preceded by a token to which columfamily you are refering. Lets focus on the first option. Say we hand out phones to our employees and we agree that every employee will always have one phone. and phones that are not used are not stored in our columnfamily. The phone has a phonenumber as key where the employee has a socialsecurity number. In order to know which number to dial when looking for employee X and who is calling giving a specific phonenumber we need to store both keys foreign in both columnfamily's. + In Cassandra modeling you are forced to either croslink both key's, So you'd design both key's foreign in both ColumnFamily's. Or you create a third ColumnFamily in which you store both keys preceded by a token to which columfamily you are refering. Lets focus on the first option. Say we hand out phones to our employees and we agree that every employee will always have one phone. and phones that are not used are not stored in our database. The phone has a phonenumber as key where the employee has a social security number. In order to know which number to dial when looking for employee X and who is calling giving a specific phonenumber we need to store both keys foreign in both ColumnFamily's. - -- CF_Employee - ---- - | | name | phone | salary | | 123-12-1234 |John | 0555-123456| 10.000 | + ||<tablewidth="400px">'''CF_Employee'''|| + ||<|2>123-12-1234||name||phone||salary|| + ||John||0555-123456||10.000|| + ||<|2>321-21-4321||name||phone||salary|| + ||Jane||0555-654321||12.000|| - ---- - | | name | phone | salary | - * | 321-21-4321 |Jane | 0555-654321| 12.000 | + ||||||<tablewidth="400px" tablealign="left">'''CF_Phone'''|| + ||<|2>0555-123456||employee||credit|| + ||123-12-1234||10|| + ||<|2>0555-654321||employee||credit|| + ||321-21-4321||5|| - ---- - -- CF_Phone - ---- - * | | employee | credit | - | 0555-123456 | 123-12-1234 | 10 | - * - ---- - * | | employee | credit | - | 0555-654321 | 321-21-4321 | 5 | - * - ---- + + Using a static columnname and requiring input in the foreign key fields, checking the existence of the key in the other columnfamily and processing updates and deletes are all subject to programming in the DBMS layer. Cassandra itself does not, and probably will not, provide foreign key logic. One could imagine an process that makes sure the cross references stay consistend: + {{{ cf_Employee.insert('321-21-4321', {'name':'Jane', 'phone':'0555-654321'}) - if cf_Phone.multiget('0555-654321', columns='employee') == {}: - - * cf_Phone.insert ('0555-654321', {'employee':'321-21-4321'}) + cf_Phone.insert ('0555-654321', {'employee':'321-21-4321'}) - else: - - * if cf_Phone.get('0555-654321', columns='employee')["Employee"] <> '321-21-4321': + if cf_Phone.get('0555-654321', columns='employee')["Employee"] <> '321-21-4321': - * raise error or delete specified employee<<BR>> + raise error or delete specified employee - + }}} ==== Subset elements ==== ''.... ''
