Mnemosyne (MNEMOSYNE)
Contents
1. init guery 1 mnemosyne 18 init guery 2 mnemosyne 18 mnemosyne all answers 1 18 cursor 1 18 cursor 2 18 delete cursor 1 18 delete guery 1 18 eval 1 18 init guery 1 18 init guery 2 18 next answers 1 18 next answers 3 18 reoptimize 1 18 setup_query 1 19 version 0 19 next_answers 1 mnemosyne 18 next_answers 3 mnemosyne 18 reoptimize 1 mnemosyne 18 setup guery 1 mnemosyne 19 version 0 mnemosyne 19 M nemosyne 25 Index of Modules and Functions 26 M nemosyne2. actual evaluation version gt String Returns the current module version List Comprehension There must be a directive in the Erlang file telling the compiler how to treat queries This directive is include lib mnemosyne include mnemosyne hrl A list comprehension consists of query lt pattern gt lt body gt end The lt pattern gt is a description of the terms that are returned by a query Details of how to obtain the actual valuesin the lt pattern gt is given by the lt body gt The lt pattern gt is an Erlang term without function calls It typically has one or more variables from the lt body gt which are instantiated for each answer produced Every element in the returned list is composed by instantiating this lt pattern gt and then adding it to the answers The lt body gt takes a sequence of goals separated by The possible goals are e lt logical variable gt lt table lt table name gt lt table type gt e lt logical variable gt lt rule lt rule name gt e lt logical variable gt lt rule lt module gt lt rule name gt e lt logical variable gt lt lt erlang list expression gt e lt expression gt lt relop gt lt expression gt e lt erlang test expression gt A lt logical variable gt is written exactly as an Erlang variable The lt table name gt lt table type gt lt rule name gt and lt module gt are atoms The lt table name gt and lt
3. deducable at Erlang compile time N ote A function used in a query list comprehension must never directly or indirectly have side effects access the database neither by a query nor by M nesia functions Spawn processes or send or receive messages PWN E Rules A rule is composed of clauses and each clause has the structure lt head gt lt body gt The clauses are separated by semicolon and the rule is terminated by a dot e The lt head gt looks like an Erlang function with one or two arguments where the first argument is a variable and the second optional argument an atom If there is a second argument it must be present in all clauses and have the same value e The lt body gt has the same syntax as the lt body gt in query list comprehensions page 4 e The argument variable of a rule clause has an associated record The default associated record is the name of the rule This can be changed by declaring the associated record type in the head of the clause lt rule name gt lt return var gt lt record name gt The syntax used in previous mnemosyne versions by declaring the the associated recordtype with an argtype declaration still works but is depreciated 6 M nemosyne 1 2 Database Oueries N ote The lt logical variable gt mentioned in the lt head gt must also occur in the lt body gt Review the rule example page 4 blocked subscribers S subscriber S lt tabl
4. rule too_high_cost 0 locates and returns all subscribers with an accumulated cost that exceeds their limit limit exceeded S subscriber S lt table subscriber A lt table account A snb S snb A cost gt S cost limit 10 M nemosyne 1 2 Database Oueries We could find all subscriber numbers of subscribers who have exceeded their cost limit as follows Q query S snb S lt rule limit_exceeded end 1 24 Matching M nesia provides the programmer with a method of matching objects against a pattern This is the M nesia matching function mnesia match_object Pattern gt transaction abort ObjList This function matches Pattern for objects A Pattern is a tuple with the name identity of the table as the first element The table collates all data retrieved In comparison to a list comprehension query mnesia match_object is a low level function The following two functions both return the same objects however the second example uses matching f10 gt 0 query E E lt table employee E sex female end F fun gt mnemosyne eval Q end mnesia transaction F and f20 gt WildPat mnesia table info employee wild pattern Pat WildPat employee sex female F fun gt mnesia match object Pat end mnesia transaction F The pattern supplied to the mnesia match object 1 function must be a valid record and the first element of the provided tuple must be a valid tabl
5. Mnemosyne MNEMOSYNE version 1 2 Typeset in IATEX from SGML source using the DOCBUILDER 3 4 1 Document System Contents 1 Mnemosyne Users Guide 1 11 Introduction ik BY Meek RR a oko kona ee A a A 1 11 1 Scope and PUrpOSe cio gt eta tea AA M A BA Bees 1 11 2 Prerequisites oca sat acai te a a noe abel Gear Grae te aoa Gn M Al Anat chant ube 1 1 2 Database QU MES ata a 4174 A Gena eet ae ae 2 1 2 1 Mnemosyne the M nesia Query Language o o 0008 2 1 2 2 Evaluating Queries lt lt lt 7 1 23 Query Examples ii A v a a ak deo 8 EZA Matching 22 as szek n u A RA A ka ee ee A 11 1 25 Matching in Record Fields lt lt lt 13 2 Mnemosyne Reference M anual 15 2 1 FAMEMIOSYVINGS oof aes ke be eo ai jang E pat lee santo abe dar V g a ate a aaa He Fa oe ae ae ee 16 List of Tables 23 Mnemosyne iii M nemosyne Chapter 1 Mnemosyne User s Guide 1 1 Introduction M nemosyne is a query language of M nesia and provides a simple syntax for complex queries N ote QLC Query List Comprehensions is another solution for queries to M nesia Ets and D ets tables which will be the recommended way to perform queries QLC belongs to Stdlib and is described there It is not recommended to use Mnemosyne queries in performance critical applications Mnesia is a distributed D ataBase M anagement System utilized for telecommunications applications and other Erlang applications which req
6. Tail Salary gt if 12 M nemosyne 1 2 Database Oueries E employee salary gt Salary gt E filter Tail Salary true gt filter Tail Salary end filter _ gt O filter deps E Tail Deps Dep gt case search deps Efemployee name Deps Dep of true gt E filter deps Tail Deps Dep false gt filter deps Tail Deps Dep end filter deps _ _ gt El search_deps Name D Tail Dep gt if D at_dep emp Name D at_dep dept_id Dep gt true true gt search deps Name Tail Dep end search deps Name Tail Dep gt false The function mnesia match object 1 will automatically make use of indices if any exist However no heuristics are performed in order to select the best index if more than one exists As can be seen the list comprehension provides a more elegant solution 1 25 Matching in Record Fields There is a difference when matching record fields in a mnemosyne list comprehension and in Erlang in general for example a function clause header The following code returns true for all employee where emp_id S 312 or 400 test employee employeefemp_id test employee ffemployeefemp id test employee gt false 312 gt true 4003 gt true That is it does not check other fields of the employee record Compare that with the following mnemosyne guery guery E E lt table employee E lt employeefemp_id 312 emp
7. abase queries are used when more complex operations than just a simple key value lookup are reguired on a database A guery can find all records in a table that fulfills a given property For example think of a table storing the status of subscriber lines in a telephone exchange A query in such a table can take the format Which subscriber lines are blocked A query can also find records on the basis of their relationship to other records in the same table or in other tables If the table which stores subscriber lines is accompanied by a table which pairs subscriber numbers with a subscriber line identification we can modify our previous query and ask Which subscriber numbers are blocked This can be answered by constructing a query which finds the blocked subscriber line identifications in the subscriber line table and then finds the associated subscriber number in the table which pairs subscriber number and subscriber line identifications H owever the proposed solution may not be the most efficient solution because it depends on what the tables look like in runtime In other words how many records the table contains and the number of different values stored In asituation where there are only a couple of subscriber numbers but a million blocked lines it would be far more efficient to first find the subscribers and then check if their line is blocked The query evaluation order depends on how large the tables are compare
8. d to each other The evaluation order also depends on key and other value distribution and if there are any indices defined refer to M nesia Chapter 5 Indexing for more information The query compiler resolves the evaluation order We need only express what we want to do and the query compiler and query evaluator will determine the best evaluation order Therefore we can express the query in the most readable form 2 Mnemosyne 1 2 Database Oueries Queries in Mnesia Queries in Mnemosyne use first order predicate logic similar to Prolog but in an syntax suitable for Erlang The query list comprehension used in Mnemosyne is taken from the functional languages community The advantage over embedded SOL is that the constructs integrate smoothly with the Erlang language To illustrate the Mnemosyne query language we will show the Erlang code for the subscriber line and subscriber number tables discussed above We define two tables subscriber and line Their corresponding record declarations in the file subscriber hr1 are record subscriber snb cost_limit 1i record line li state The query which subscriber numbers are blocked can also be expressed as which subscribers have lines which are in state blocked This query can be coded as follows query S snb collect the subscriber number S lt table subscriber where S is taken from the subscriber table L lt table line and L i
9. e operation N ote This must be evaluated inside a transaction init_query QuerySetup gt Cursor init guery OuerySetup Nprefetch gt Cursor Performs the last short step in starting a query from QuerySetup Nprefetch defines the number of answers to pre fetch as in cursor 2 The default value is 1 Note This must be evaluated inside a transaction next answers Cursor gt Answers next answers Cursor Nmin Nmax gt Answers Fetches the next answers from the guery evaluation identified by Cursor At least Nmin and at most Nmax answers are collected If less than Nmin answers are returned for example 0 there are no more answers If enough answers are not available but more are expected the functions wait for them Note This must be evaluated inside a transaction reoptimize Handle gt Handle 18 M nemosyne Mnemosyne Reference M anual mnemosyne Re optimizes a query Queries are always optimized but the optimization takes into account the dynamic table statistics like size attribute distribution etc If a table has changed after obtaining the Handle from a query list comprehension the query execution plan will no longer be appropriate although semantically correct This function will rearrange the execution plan according to the current statistics from the database setup_query Handle gt QuerySetup Creates a query setup that is performs most of a query evaluation without actually initiating the
10. e a stores records with the name a Since release 3 4 of M nesia it has been possible to separate record name and its table type If the type of the table is different from its name this can be specified in Mnemosyne using X lt table Name Type where Name is the N ame of the table and Type is the record name Similar to tables rules produce or test records The return type for a rule is by default the name of the rule Rules can be declared to return other types This makes it possible to construct arule for some special cases with a name like blocked_subscriber which still produces or tests subscriber records In Erlang we must always tell the compiler which record definition it should use by putting the record name after a hash mark In general this is not needed in Mnemosyne since in most cases the query compiler can deduce the associated record That is the reason S 1i is acceptable instead of the full S subscriber 1i It will not cause an error if the longer version was written but if we do write the record name it must be the same record name as the one the query compiler deduces Sometimes the compiler is unable to find the associated record When this happens an error message is issued It is also preferred to write out the type of the associated record for performance reasons If the associated record is part of a complex constraint the constraint may be compiled to a function if the type of the associated record is known explicitly or
11. e name The special element matches all the records There are advantages in using the M nemosyne guery syntax instead of the mnesia match object 1 function e The pattern is computed in compile time by the M nemosyne compiler instead of doing it in run time in the 2 0 function e Mnemosyne provides more sophisticated evaluation optimizations based on indices and on statistics from and about the table Whereas the optimizations that mnesia match_object 1 function provides are limited in both scope and number The mnesia match_object function is also performed during run time which in turn reduces performance e The Mnemosyne query syntax is quite compact and makes it easier to express complex queries It is also possible to use the match function if we want to check the equality of different attributes Assume we have the following record definition Mnemosyne 11 Chapter 1 Mnemosyne Users Guide record foo fa b c The pattern foo 1 gt 1 _ then extracts all objects of type foo where the first two attributes have the same value If the key attribute is bound in a pattern the match operation is very efficient The pattern foo 123 _ elvis can be used to extract all objects with key 123 and the last attribute set to the atom elvis This is the same as extracting all the elvis objects from the result of mesia read foo 123 but more efficient If the key attribute in a pattern is given as _
12. e subscriber L lt table line L state blocked L li S 1i It produces a list of subscriber records Rules with a single argument return records of the same type as the name of the rule For example the following rule produces records of type blocked record blocked snb li blocked X S lt table subscriber L lt table line L state blocked L li S li X blocked snb S subscriber snb 1i S subscriber 1li 1 2 2 Evaluating Queries The previous sections described how to define queries This section describes how to evaluate queries The principle is simple query list comprehensions compile and optimize the query and return a handle This handle is then passed on for execution Handle query S snb S lt table subscriber S li none end AllAnswers mnesia transaction fun gt mnemosyne eval Handle end There are three ways of evaluating queries The mnemosyne eval 1 is the simplest of the three It takes a handle and returns all solutions Sometimes we only need to view a few solutions examine them and possibly get more Think of an airline routing database you do not want to know all possible connections between two cities but usually enough information is given after observing one or two Use the cursor with a query evaluation to produce a few solutions only With a handle we create a cursor by calling mmemosyne cursor 1 With the cursor we can repeatedly call mnemo
13. example formulated as a rule would look as follows blocked_subscribers S subscriber S lt table subscriber L lt table line L state blocked L li S 1i This rule can be used in a guery in the same manner as a table but with the keyword rule substituted for table query S snb S lt rule blocked subscribers end Ouery Syntax D atabase queries can be included in an Erlang program but there must be a directive in the Erlang file which informs the compiler about its behavior towards queries This directive is include lib mnemosyne include mnemosyne hrl The high level syntax of the guery list comprehension is guery lt pattern gt lt body gt end The lt body gt is a comma separated seguence of lt logical variable gt lt table lt table name gt lt table type gt lt logical variable gt lt rule lt rule name gt lt logical variable gt lt rule lt rule name gt lt logical variable gt lt rule lt module gt lt rule name gt lt logical variable gt lt lt erlang list expression gt lt expression gt lt relop gt lt expression gt E E DY E lt erlang test expression gt The lt relop gt operators are e for unification e for not unification e lt for lessthan e gt for greater than e lt for egual to or lessthan e gt for equal to or greater than 4 M nemosyne 1 2 Database Oueries A lt logical variable gt is wri
14. le we will get just five names record person name age Handle query P name P lt table person end QuerySetup mnemosyne setup_query Handle L mnesia transaction fun gt Cursor mnemosyne init_query QuerySetup mnemosyne next answers Cursor 5 5 end Here we may call more init guery next answers constructions with the same Handle mnemosyne delete_query QuerySetup M nemosyne 17 mnemosyne Mnemosyne Reference Manual Exports all_answers Cursor gt Answer Returns all remaining answers from the query identified by Cursor It can be applied after next_answers to obtain all answers that are left N ote This must be evaluated inside a transaction cursor Handle gt Cursor cursor Handle Nprefetch gt Cursor Sets up a query for evaluation and starts an answer pre fetch Nprefetch gives the number of answers to pre fetch and must be greater than 0 The default value is 1 A pre fetch is the first part of a query evaluation It is placed in a separate process which may on some occasions speed up the subsequent collection of answers N ote This must be evaluated inside a transaction delete_cursor Cursor D eletes the Cursor and associated query evaluation N ote This must be evaluated inside a transaction delete_query QuerySetup D eletes a query setup eval Handle gt Answers Starts a query evaluation according to the Handle and collects all answers in on
15. loyeefemp_id 400 Mnemosyne 13 Chapter 1 Mnemosyne Users Guide The guery will return all employees from the employee table whos emp ia is either 312 or 400 and have the other fields set to the default values for an employee To select all items that have a field set to some values disregarding the other fields the constraint can be put in separate function For example select all employees whos emp ia is either 312 or 400 independently of other fields query E E lt table employee test employee E test employee femployeefemp id 312 gt true test employee femployeefemp id 400 gt true test employee gt false If there is only one acceptable value for a record field it is more efficient to write it directly in the query Select employees whos emp id is 312 query E E lt table employee Efemployee emp id 312 14 M nemosyne Mnemosyne Reference Manual Short Summaries e Erlang Module Mnemosyne page 16 A query language support for the DBMS M nesia Mnemosyne The following functions are exported e all_answers Cursor gt Answer page 18 Return all answers from Cursor in a list cursor Handle gt Cursor page 18 Create a cursor in preparation for fetching answers cursor Handle Nprefetch gt Cursor page 18 Create a cursor in preparation for fetching answers e delete cursor Cursor page 18 Stop the query associated with Cursor e delete_query QuerySetu
16. n gt and in some places as described above They must always be bound in the query list comprehension Errors in the description are reported as exceptions in the Erlang standard format as follows error Line Module Msg The descriptive English text is returned by calling Module format_error Msg N ote A function used in a query list comprehension must never directly or indirectly 1 have side effects 2 access the database either by a query or by Mnesia functions 3 spawn processes 4 send or receive messages Rules Views A rule or view is a declaration of how to combine data from sources as a kind of subroutine Assume that we have the following query list comprehension query Employee Employee lt table employee Employee department sales end This retrieves a list of all sales employees This could be formulated in the following rule sales E employee E lt table employee E salary sales Mnemosyne Mnemosyne Reference M anual mnemosyne The employee declaration in the head of the rule forces the rule argument to associate the employee record If we omit the declaration then the associated record would be the rule name in this case sales N ote that the syntax used in previous versions of M nemosyne by using an separate argtype declaration still works but the above method is prefered The sales rule may now be used in a query list comprehension query SalesPers
17. nctions are marked in the function descriptions below After obtaining a handle from a query list comprehension the query can be evaluated in three different ways e A simple all answer query as in the example shown above This function is eval 1 e Getting the answers in small or large chunks The query may be aborted when enough solutions have been obtained These are called cursors The functions are cursor 1 cursor 2 next_answers 1 next answers 3 all_answers 1 all_answers 3 and delete_cursor 1 e An even more sophisticated cursor version where the time consuming part of the cursor creation can be done in advance The functions are setup_query 1 init_query 1 init_query 2 next_answers 1 next_answers 3 all_answers 1 all_answers 3 and delete_query 1 Let us reconsider the previous example this time with cursors In the following example we will get just five names without evaluating all of the answers record person name age Handle query P name P lt table person end L mnesia transaction fun gt Cursor mnemosyne cursor Handle As mnemosyne next answers Cursor 5 5 mnemosyne delete cursor Cursor As end The third way of evaluating a query is by a further division of the query process The cursor 1 function is now split into two The reason for this is that we can set up the query when there is plenty of time and initialize it when answers are needed quickly As in the previous examp
18. nemosyne hrl module subscriber compile export all include subscriber hrl include lib mnemosyne include mnemosyne hrl We then create the reguired tables and load data by entering table definitions into a file named subscriber tables which has the following content ftables subscriber attributes snb cost_limit li fline fattributes li state account fattributes snb cost F Subscribers subscriber 1230 0 none Mnemosyne 9 Chapter 1 Mnemosyne Users Guide subscriber 1231 0 none fsubscriber 1232 0 none fsubscriber 1233 0 none fsubscriber 1234 100 li i fsubscriber 1235 200 1i 3 fsubscriber 1236 150 1i 2 fsubscriber 1237 0 none fsubscriber 1238 0 none subscriber 1239 0 none 44 Lines line li 03 blocked fline 11 1 normal fline 11 2 normal fline 11 3 blocked fline 11 4 blocked fline 11 5 blocked fline 11 6 blocked fline 11 7 blocked 44 Accounts account 1234 0 account 1235 0 account 1236 0 account 1237 0 Program Output In our program this file is called with the statement mnesia load textfile subscriber tables To retrieve a list of all free subscriber numbers we call the following function in a transaction free subscriber numbers gt mnemosyne eval guery S snb S lt table subscriber S li none end The
19. on SalesPerson lt rule sales end The SalesPerson is an employee record because of the declaration of the rule above Another example lists the names of all female sales people guery SalesPerson name SalesPerson lt rule sales SalesPerson sex female end The rule must have one argument when used Although the declaration of a rule looks similar to an ordinary function no function of that name is constructed Hence the name of the rule can be used for another function All rules are automatically exported so they could be referred in other modules by the usual notation module name After the there is the usual lt body gt as in the query list comprehension Generated Functions When compiling queries some extra hidden functions are automatically generated and exported Thus there cannot be other functions with the same name and arity within the module Three such generated functions exist They are e MNEMOSYNE QUERY 2 e MNEMOSYNE RECFUNDEF 1 e MNEMOSYNE RULE 1 M nemosyne 21 mnemosyne Mnemosyne Reference Manual 22 M nemosyne List of Tables 1 1 Natural Language Translation M nemosyne 23 List of Tables 24 M nemosyne Index of Modules and Functions M odules are typed in this way Functions are typed in this way all answers 1 mnemosyne 18 cursor 1 mnemosyne 18 cursor 2 mnemosyne 18 delete_cursor 1 mnemosyne 18 delete_query 1 mnemosyne 18 eval 1 mnemosyne 18
20. or 1 the whole foo table must be searched for objects that match If the table is large this may be atime consuming operation This can be remedied with indices refer to M nesia C hapter 5 Indexing for more information This chapter closes with an example of information extraction from a Company database e all employees who have a salary higher than X e all employees who work in the Dep department The first example demonstrates the query execution with list comprehension notation The second example illustrates a query coded with a matching function The list comprehension based implementation looks as follows get_emps Salary Dep gt Q query E E lt table employee At lt table at_dep E salary gt Salary E emp_no At emp At dept_id Dep end F fun gt mnemosyne eval Q end mnesia transaction F The data model for the Company database introduced in the M nesia documentation was designed to facilitate the posting of gueries like the one shown above To implement the same guery by directly searching the database is more complex The following function does precisely this get emps2 Salary Dep gt Epat mnesia table info employee wild pattern Apat mnesia table info at dep wild pattern F fun gt All mnesia match object Epat High filter All Salary Alldeps mnesia match object Apat filter deps High Alldeps Dep end mnesia transaction F filter E
21. p page 18 D elete a query setup e eval Handle gt Answers page 18 Get all answers from the Handle e init_query QuerySetup gt Cursor page 18 Quick query initialization e init_query QuerySetup Nprefetch gt Cursor page 18 Quick query initialization e next_answers Cursor gt Answers page 18 Fetche the next answers e next_answers Cursor Nmin Nmax gt Answers page 18 Fetche the next answers e reoptimize Handle gt Handle page 18 O ptimize a guery e setup guery Handle gt QuerySetup page 19 Create a guery setup version gt String page 19 M nemosyne module version M nemosyne 15 mnemosyne 16 Mnemosyne Reference Manual mnemosyne Erlang M odule O ueries are used for accessing the data in a D atabase M anagement System The query specifies a relation possibly complicated to all of the selected data This could involve several tables as well as conditions such as c less than function calls and similar M nesia has two query interfaces which are used together e Mnemosyne which is this module e QLC Query List C omprehensions an Erlang language construct for the queries This will be the recommended way to perform queries The exact syntax of query list comprehensions are described in a separate section page 19 of this document The query list comprehensions only define the query and the syntax of the solutions to be returned The actual evaluation is determined b
22. s taken from the line table L state blocked and the state of that line is blocked L li S li and L and S uses the same li end In the example above the aim is to get an answer from a logical relation C onsider also the following example query E name E lt table employee E sex female end This means the Erlang list of all female employees A formulation closer to the list comprehension is the Erlang list of all names of E such that E isin the table employee and E s sex is female Some words have a direct correspondence to the elements in the list comprehension notation the Erlang list of all such that isin and Table 1 1 Natural Language Translation Another query component is rules which can be compared to views in Relational D atabases where the purpose is to define a virtual table This table looks like an ordinary table to the user which means Mnemosyne 3 Chapter 1 Mnemosyne Users Guide that gueries can be formulated on stored data as well as views In the subscriber line example a rule can give the subscriber number and the corresponding line status from both tables and there is no need to create a third table The rule is a definition of how to calculate the records on demand from a query In Erlang modules rules are written with the same syntax as the bodies in the query list comprehensions They are exported and can be used by other modules Our subscriber
23. syne next answers to get more solutions When an empty list is returned there are no more possible solutions Delete the cursor with mnemosyne delete cursor 1 Mnemosyne 7 Chapter 1 Mnemosyne Users Guide Handle query S snb S lt table subscriber S li none end AFewAnswers mnesia transaction fun gt Cursor mnemosyne cursor Handle now get at least two but not more than five solutions L mnemosyne next answers Cursor 2 5 mnemosyne delete cursor Cursor L end A query evaluation can be time consuming but can be broken up by using the cursor with setup_query 1 and init_query 1 Handle query S snb S lt table subscriber S li none end QuerySetup mnemosyne setup_query Handle AFewAnswers mnesia transaction fun gt Cursor mnemosyne init_query QuerySetup mnemosyne next answers Cursor 5 5 end Here we may call more init guery next answers constructions with the same Handle Note that the query is evaluated from scratch because of the call to mnemosyne init_query 1 mnemosyne delete_query QuerySetup Because of table updates a query which is compiled and optimized may be incorrect when the handle returns This can be rectified with the function mnemosyne reoptimize 1 which takes a handle re optimizes the query and returns anew handle 1 2 3 Query Examples This section describes an example which illustrates the use of Mnemosyne The e
24. t logical variable gt lt This expression means that the variable is taken from the values in the expression to the right of the arrow For example E lt e a 1 e a 2 saysthat E takes the values e a 1 or e a 2 lt These constructs usually generate values However if the logical variable is bound it tests that value If a test fails it means that the query tries another alternative For example query X a X lt ef a 1 e a 2 X lt e a 3 wal end The body means that the field a of X should be 3 and at the same time either 1 or 2 So the list of solutions will always be empty Thetest lt expression gt lt relop gt lt expression gt and the true or false returning test lt erlang test expression gt simply filters out the solutions The purpose of the latter test is to provide user defined data tests We will next consider the logical variables associated records in an expression like x lt table a We have already established the following rules and assumptions 1 the values stored in tables are records 2 all recordsin a table must be of the same type 3 by default the record definition has the same name as the table itself 4 The lt logical variable gt must have the same record association as the records produced by the right side of the lt constructs Mnemosyne 5 Chapter 1 Mnemosyne Users Guide Inthe example X lt table a the associated record of x isa because tabl
25. table type gt may be an Erlang variable which must be bound at runtime The logical variables are local to a list comprehension and shadows any Erlang variables with the same name An lt expression gt is any Erlang expression which may include function calls and lt logical variable gt The variants lt erlang list expression gt is an lt expression gt which must produce lists where all elements are records of the same type The lt logical variable gt must have the same associated record The Mnemosyne 19 mnemosyne 20 Mnemosyne Reference Manual lt erlang test expression gt iS an lt expression gt which only has the values true or false Erlang variables are allowed in all variants of lt expression gt and in lt pattern gt They must always be bound in the query list comprehension logical variables is local to a query list comprehension and have an associated Erlang record The associated record can in most cases be inferred by the query compiler Therefore the normal notation for the field 1 in variable x is just X f1 The query compiler notifies when it cannot deduce the corresponding record The explicit form is X r 1 asin ordinary Erlang If the type of the record is not deducable at Erlang compile time it is more efficient to use the explicit form as a help to the compiler A variable receiving values from a table will have the record with the same name as the table Erlang variables are allowed in lt expressio
26. tten exactly as an Erlang variable The lt table name gt lt table type gt lt rule name gt and lt module gt are atoms The lt table name gt and lt table type gt can also be an Erlang variable The logical variables are local to a list comprehension and shadows any Erlang variable with the same name The lt pattern gt is an Erlang term without function calls It may contain bound Erlang variables and it usually has one or more lt logical variable gt since these are used to get data out from the query body and into the produced list An lt expression gt is any Erlang expression which may include function calls and lt logical variable gt The variant lt erlang list expression gt iS an lt expression gt which must produce a list where all elements are records of the same type The lt erlang test expression gt is an lt expression gt which has the values true or false Erlang variables are allowed in all variations of lt expression gt and in lt pattern gt They must be bound in the guery list comprehension Ouery Semantics The constructs used in the M nemosyne guery language have the following meanings e Comma The comma used to separate different body elements is eguivalent to and Thus the body can be viewed as a collection of tests and statements which should be true for each solution which is produced when evaluating the guery list comprehension Refer to subscriber guery page 3 as an example of this l
27. uire continuous operation and soft real time properties M nesia is part of the O pen Telecom Platform OTP which is a control system platform for building telecommunications applications 1 1 1 Scope and Purpose This manual is included as a part of the OTP document set It describes how to use Mnemosyne queries Programming constructs are described and numerous programming examples are included to illustrate the use of Mnemosyne 1 1 2 Pre requisites It is assumed that the reader is familiar with system development principles and database management systems Readers are also assumed to be familiar with the Erlang programming language in general and the Mnesia application in particular Mnemosyne 1 Chapter 1 Mnemosyne Users Guide 1 2 Database Queries This chapter describes Mnemosyne the M nesia database query language and the syntax semantics and rules which apply to M nesia queries The following sections are included e Mnemosyne the M nesia query language e Evaluating queries e Mnesia query examples e Matching e Generated functions The following notational conventions are used in this chapter e Reserved words and symbols are written like this table e Syntactic categories are written like this lt pattern gt 1 2 1 Mnemosyne the Mnesia Query Language M nemosyne is the query language and the optimizing query compiler for the M nesia D atabase M anagement System General Information about Oueries Dat
28. xample given is of a simplified local exchange with A X E 10 exchange as a model The purpose of this section is to show different constructs in a telecom environment It should not be taken as a proposed data model for a modern telecom system O ur telephone example includes the following components relationships and events 8 M nemosyne 1 2 Database Oueries The exchange has a number of subscribers Each subscriber has a subscriber number which is abbreviated snb Each physical line enters the exchange through a line interface card Lines are abbreviated li The li has an associated status which indicates if the line is blocked or available One single table stores the accumulated cost for each subscriber Program Definitions We identify three tables e subscriber with subscriber numbers snb line interface number li and a maximum cost cost_limit which must not be exceeded e line with line interface number li and its state e account atable which stores the cost of calls It has an snb field and the accumulated cost in cost The corresponding record definitions are stored in a file named subscriber hrl which has the following record definitions record subscriber snb cost_limit li record line li state record account snb cost The program file is titled subscriber er1 It declares the module name subscriber calls the record definition in subscriber hr1 and M nesia query support m
29. y calling different functions with a handle obtained by the list comprehension For example record person name age Handle query P name P lt table person end L mnesia transaction fun gt mnemosyne eval Handle end The example above matches a list of all names in the table person with the variable L N ote the following points e Each database table must have a corresponding record declaration e A query is declared with query lt pattern gt lt body gt end where lt pattern gt is an Erlang term without function calls The notation P name means that P is a variable and it has an associated record with a field name which we use The lt body gt is a sequence of conditions separated by commas In the example wehave P lt table person which means P is taken from the table person The whole query could therefore be read as follows M ake the list of all names of P such that P is taken from the table person H owever the query list comprehension does not return the answers but a handle This handle is used as an argument for different evaluation functions which do the actual query processing In the example we used the simplest eval 1 which evaluates the query and returns all the answers Mnemosyne Mnemosyne Reference M anual mnemosyne e Some parts of the query must be evaluated in a M nesia transaction or by utilizing an alternative M nesia access context These fu
Download Pdf Manuals
Related Search