I have a question as follows:
A primary school class contains a number of children and a variety of books. Write a model which keeps track of the books that the children have read. It should maintain a relation hasread between children and books.
So I have my context as so
CONTEXT
booksContext
SETS
STUDENTS
BOOKS
CONSTANTS
student
book
AXIOMS
axm1: partition(STUDENTS, {student})
axm2: partition(BOOKS,{book})
And my machine is as follows:
MACHINE
books
SEES
booksContext
VARIABLES
students
readBooks
INVARIANTS
students ⊆ STUDENTS
readBooks ⊆ BOOKS
readBooks ∈ students → ℕ
readBooks ∈ students → ℕ is trowing up an error. Obviously I am modelling this wrong. Can any body help me with this? I am new to event B and I really don't know what to do
readBooks variable can't be both a subset of BOOKS and a total function because BOOKS isn't a total function from STUDENTS to ℕ.
The fixed model can be found in this question.
It looks like this:
MACHINE
books
SEES
booksContext
VARIABLES
students
books
readBooks
INVARIANTS
students ⊆ STUDENTS
books ⊆ BOOKS
readBooks ∈ students → books
where readBooks is a total function from the set of students to the set of books that these students have read.
Related
I'm using Flutter/Dart but this is really a basic OOP question I have for all languages.
I'm looking for an answer that tells me which of the designs below have the best resource management as well as easiest coding.
This similar post does not really satisfy me, I feel I need a better black & white answer that can discern the two designs.
Situation One
A rarely modified object which gets created once but read somewhat often and updated rarely
Situation Two
A heavily accessed object- mainly read actions but very regularly created, a great many objects 1000+ & they will be regularly filtered
Example:
List<SalesIncome> salesIncome = "Sales income from DB";
num totalSalesIncome = salesIncome.where((salesPerson) =>
salesPerson.contains('John Lohn')).toList().reduce((a, b) => a + b);
Which of the two has best resource management (memory & CPU) & best codeability for CRUD actions further down the chain at end of API? Not asking a subjective question.
To clarify, I want to know which object design #1 or #2 is best for each situation 1 & 2.
enum TimePeriod {weekly, monthly, yearly}
#1
class SalesQuota {
String salesPerson;
TimePeriod quotaPeriod;
num grossIncomeQuota;
int quotaDate;
}
#2
class SalesQuota {
String salesPerson;
TimePeriod quotaPeriod;
Map<int, num> quotaData;
}
Example for multiple object creation:
#1
SalesQuota(
John Lohn,
TimePeriod.weekly,
45600.00
1646125200000)
SalesQuota(
John Lohn,
TimePeriod.weekly,
50000.00
1646730000000)
SalesQuota(
John Lohn,
TimePeriod.weekly,
65000.00
1647331200000)
SalesQuota(
John Lohn,
TimePeriod.weekly,
68000.00
1647936000000)
#2
SalesData(
John Lohn,
TimePeriod.weekly,
{
1646125200000: 45600.00,
1646730000000: 50000.00,
1647331200000: 65000.00,
1647936000000: 68000.00,
}
I have this path
(user)-[like]->(book)
Now I want to get a list of all books with all users that liked a book
USER BOOK
[user, user] book
[] book
[user] book
I have only found examples with a starting point but in this case there isn't.
Under the assumption that you have created a document collection book and user and a edge collection like:
FOR b IN book
LET u = (FOR v IN 1 INBOUND b ##edgeCol RETURN v)
RETURN { book: b, user : u }
The ##edgeCol is a bind parameter and has to contain the name of your edge collection (in your case like).
This query should return you an array of documents with field book which includes your book document and an array user with all user documents who likes the book. If the query returns you an empty array of users for each book, you probably have to change the direction INBOUND in the query to OUTBOUND depending on the direction of your edges.
For more information about graph traversals in AQL you should take a look into the docs.
I am trying to learn alloy but i am having a hard time finding proper learning material.
So i am trying some models by myself and see if they works.
I wanted to find and return the clinics containing the given doctor with the function but it is not working. How can i do this without changing the Clinic and Doctor?
abstract sig Clinic {
doctors : set Doctor
}
abstract sig Doctor {}
fun getClinicsOfDoctor [ d : Doctor ] : set Clinic {
all c : Clinic | d in c.doctors
}
What material have you looked at? Try the Alloy book. Also see tutorials and papers on the Alloy website.
What's wrong with your model is that the body of your function is a formula. It should instead be an expression. Any of the following will work
doctors.d
d.~doctors
{c: Clinic | d in c.doctors}
I have the following relation in which I want to search
class Order {
static hasMany = [articles:Article]
}
class Article {
}
In my search I select N articles and I want to find all Orders that contain all the N selected articles. So far I was only able to find all Orders that contain one of the selected Articles. It would be great if anyone can help me on this.
Order.executeQuery("select o from Order o join o.articles as a where a in (:articleList)", [articleList: articleList])
I'm vainly attempting to learn how to use object databases. In database textbooks the tradition seems to be to use the example of keeping track of students, courses and classes because it is so familiar and applicable. What would this example look like as an object database? The relational database would look something like
Student
ID
Name
Address
Course
ID
Name
PassingGrade
Class
ID
CourseID
Name
StartTime
StudentClass
ID
ClassID
StudentID
Grade
Would you keep StudentClasses inside of Classes which is, in turn, inside Course and then keep Student as a top level entity?
Student
ID
Name
Address
Course
ID
Name
Classes[]
Name
StartTime
Students[]
StudentID
So you have Courses, Students and Classes, which are parts of Courses and visited by Students? I think the question answers itself if you think about it. Maybe it's clearer if you go away from the pure JSON of MongoDB and look at how you would define it in an ODM (the equivalent of an ORM in RDBs) as document based DBs don't really enforce schemas of their own (example is based on MongoEngine for Python):
class Student(Document):
name = StringField(max_length=50)
address = StringField()
class Attendance(EmbeddedDocument):
student = ReferenceField(Student)
grade = IntField(min_value=0, max_value=100)
class Class(EmbeddedDocument):
name = StringField(max_length=100)
start_time = DateTimeField()
attendance_list = ListField(EmbeddedDocumentField(Attendance))
class Course(Document):
name = StringField(max_length=100)
classes = ListField(EmbeddedDocumentField(Class))
This would give you two collections: one for Students and one for Courses. Attendance would be embedded in the Classes and the Classes would be embedded in the Courses. Something like this (pseudocode):
Student = {
name: String,
address: String
}
Course = {
name: String,
classes: {
name: String,
start_time: DateTime,
attendance_list: {
student: Student,
grade: Integer
}[]
}[]
}
You could of course put the grade info in the student object, but ultimately there really isn't much you can do to get rid of that extra class.
The whole point of an OODBMS is to allow you to design your data model as if it were just in memory. Don't think of it as a database schema problem, think of it as a data modelling problem on the assumption that you have a whole lot of VM and a finite amount of physical memory, You want to make sure that you don't have to boil an ocean of page faults (or, in fact, database I/O operations) to do the operations that are important.
In a pure OODB, your model is fine.