What is the difference between a validation rule and a business rule ?
As per my understanding, 'if the state of the business object/objects is not as expected, then throw an error message' is a validation rule, and 'when the state of the business object/objects is or is not equal to something, then change the state of some business object/objects [or take some action/event but not just throw an error]' is a business rule.
Validation can be UI validations - validate values of UI fields or application validations - validate business object states.
I am not sure whether my understanding above is correct. In my project, we have a validation framework, where a simple validate call takes business objects to validate against something and an error collector that collect all errors. The errors are displayed on the screen afterwords.
In addition to that, we have rules that falls in second category as described above i.e check the business object/objects state and take some action such as change the state of another business object. I am trying to find out the strategy to implement such rules either using some framework [not a validation framework] or a rule engine.
Can you please help me understanding the distinction between the above 2 kind of rules and if there are any implementation strategies/ recommendations, it would be helpful.
A validation is a check that the value entered is legitimate for the context of its field (from technical perspective), for example: is 5 as a numeric value acceptable for Age(v.s. -5)?, while -5 is acceptable as Temperature for example.
The business rule is more of a business perspective. It is a check that the values (that passed the validation) are acceptable by the policies and procedures of the business. E.g. the person who is allowed to register has to be a resident, and 18 years old or more..etc. The business rule might check one (or more) field(s) value(s), and might consult data stored in a database and/or do some calculation(s) to ensure that the value(s) pass the business rules.
So, for the example posted above by hanna, the value 15 should pass the field validation (as it is a valid value for Age), but it will not pass the business rule check that the married person's age must be >15.
In short; a validation rule determines basic validity; "is this a valid email address?" A business rule determines what to do with the valid data; "can I set the user's confirmation email to the submitted value?" Business rules can migrate into validation logic; but typically, validation is not done by the business rule engine.
Validation usually refers to rules that it is not required to query database for validating them. For example minimum password length.
Business rules usually require a database query for validating. For example you can not withdraw money more than your account balance. And this is a business rules.
So for example, minimum acceptable age for registering for school that is hard coded in the application is a validation rule.
A business rules, from its name, it is a data check from business point view, for example, the marital status can not be "married" and the person age is less than 15, it is basically rules that change from business to business.
validation, it is usually related to user interface , can be common in more than on business,and can be derived by common sense, for example, the email format should have a specific form, or if there is a start date and end date, the end date inserted should be bigger than the one inserted in the start date.
It all depends on perspective. Both validation rules and business rules are really the same thing. We sometimes logically categorise how complex rules are, the most basic being Validation then more complex being Business rules. That's not correct, as it depends! Example of "complexity rule hierarchy":-
Basic datatype
Usually conversion from a string into strong type, examples
A number cannot be "hello"
Boolean is yes/no or True/False.
Metadata on type/common sense
Now we have a strong type, check bounds, getting more blurry
Future booking date is not historic (before now)
Year in century, number in range 1 to 100
Notes max 100 chars.
Business rules
Now fully ambiguous...it depends!
If System Health Check account then Email is mandatory but must be malformed "not-an-email".
Cannot place order more than 1000USD, if credit limit is "Basic"
Notes must be min 200 chars if is Manager.
Did you notice a Manager must make 200 chars of Notes minimum, whilst others zero to max 100.
Thus some may argue max chars is validation, but clearly the business requires Managers do more. So which is it?
Maybe call everything a Business Rule as the ultimate goal of validation is to ensure "data correctness in all business contexts".
Related
I am modeling some processes in a system and draw it in BPMN. But I confuse, can I use 2 actors in one lane? because they have the same task from start to end. they don't have differences in that business process. like the picture show. so can I? or how can I fix that?
This is the business process:
In my opinion it shouldn't be that way.
Each actor has a specific business scope if you wanna call it.
First describe best the scope of activities involved in each actor, then look of the departments interact. Wich actor has a bigger scope than the other. Why?.
Example in your case both the first actor should take care of both 2 task, and scalate them if something happen that needs a more experienced opinion. Or just if some outcome of the first task it's outside the scope of the first actor. Let's say :
First Actor takes care or approved checks up to $5000.
The first task involves putting all the details of the check as the amount.
When the first task end the outcome can be Greather/equals than $5000 or less than $5000.
Case 1 [amount < $5000]If the outcome it's less then a task for the first actor it's created when an action available it's to approve the check.
Case 2 [amount >= $5000] If the ourcome it's greather/equals then a new task it's made for the second actor, wich will require it's approvement.
Also to say in this scenario we will have 3 task, 2 for the first actor (input check task, approve low budget checks) and 1 for the second actor (approve of high budget checks).
Usually this over specification can be replaced by using some scalating mechanism. Usually involving timeframes required for the first task to be operated but it can't be based in other details too. Hope it helps . Best!
This depends a good bit on some additional context. If I were implementing this solution using a tool where the diagram is interpreted and used at runtime, my answer may be different than if I'm simply using BPMN as a good tool for capturing my Business Process.
The first question I would have if my customer modeled a process in this manner is "So, please confirm, based on this diagram, it for every instance of the process it is equally valid for either the Visitor or the Admin to execute task 1 and 2." That seems a bit unlikely to me, since based on that, any visitor could execute these tasks, no matter what their relationship to the underlying instance of the process.
For example, lets say you were capturing something where I, as the visitor should fill out a form (task 1), but you are trying to accomidate that in some situations the Admin might fill out the form for me. If makes sense that either I can fill out the form for myself, or the Admin can, but it doesn't make sense that you, a person totally unrelated to me and not an Admin, would be allowed to fill out the form.
If I were modeling the above scenario (who fills out the form) I would likely have a decision gateway after the start that would evaluate "Is Andrew going to do this?". A yes would go to "Fill out form" activity for me, and a "No" would route to the "Fill out form" for the Admin.
As in many things in life, there isn't a clear answer, especially when the thing you have asked is so abstract. I can come up with examples where either model is valid, but would need the specifics to get it right.
I always think that an address data is a value object since it is immutable and its equality is defined by the same data in all fields. For example, a billing address in a part of a payment and a shipping address is a part of an order or a fulfillment. When someone changes her/his address, a new address data is needed. But, every single sample code/application, I have run into, has an address data as an entity, which its DB table has its own ID. It would make a sense if a system wants to keep track of all addresses where all business activities/events occur. I, however, don't see such intention in those sample code/application. Do I miss something in the regard?
You can't generalize.
Examples are one thing, real world problems are another. You can't say that for all projects one solution fits it all.
I'll give you an example I had in a project conserning aggregate roots.
Logically and legally a subsidiary is an extension of its company, eg. Walmart has its HQ with tax number and everything and subsidiaries without tax number where the actual stuff is sold. Logically, for applying to a goverment funding or something similar, the HQ sends a request for its subsidiary. Here, Walmart HQ is an aggregate root and its subsidiary is a part of an aggregate in funding procedures.
This is a logical example.
What I had is that a subsidiary can legally apply for state funding without the knowledge of HQ! Therefor, HQ is not an aggregate root anymore, but a subsidiary is. It was extremely illogical, but those were the business requirements.
The point is the same with your value object question. Although you can use Address as an example that it is an entity or a value object, it is the requirements of the business that dictate what an address is, and not what is logical.
Pre-note: there are domains where an address should be an entity, like a mail service; we do not talk about those domains
From my experience, people tend to implement an address as an entity because of the persistence: it is easier to persist an address as a sub-entity to a relational database than to persist a value object because of the entities ID that act as primary keys in the storage table.
However, there are tactics that permit storing a value object as an database entity but still using it just as a value object, as it should be. Vaughn Vernon shows how to do this in his book, Chapter 6, sub-chapter Persisting Value Objects.
I need to Validate SSN in such a way that redundant entry should not appear. for example if a message arrives for Patient A with ssn 123-45-6789 and next time if any message comes for Patient B with same ssn, integration engine should catch this. I am using cloverleaf as a integration engine and need to validate this.
please let me know if any logic can be suggested.
Thanks,
Anupam..
That wouldn't be a valid use case for an integration engine. You should look into acquiring a master patient index application and integrate it into your message flow.
Even then, with HL7 messaging there is generally no 100% reliable source of truth to tell you who is Patient A and who is Patient B. For example, if you get a second message for SSN 123-45-6789 and the name doesn't match the first patient is that because it's really a different person or did the patient perhaps legally change her name?
Finally relying on SSNs in health care systems is generally considered a bad idea due to the security and privacy concerns. Most modern systems actually filter out SSNs and rely on other fields to identify the patient.
I'm creating a messaging system for a e-learning platform and there are some design concerns that I'd like some feedback on.
First of all, it is important for me and my system to be highly modifiable in the future. As such, maintaining a fairly high normalization across my tables is important.
On to how my system will work:
All members (students or teachers) are part of a virtual classroom.
Teachers can create tasks and exercises in these classrooms and assign them to one or multiple students (member_task table not illustrated).
A student can request help for a specific task or exercise by sending a message to the teachers of the classroom.
Messages sent by students are sent to all the teachers. They cannot address a message to a specific teacher.
Messages sent by teachers can be addressed to one or more students.
Students cannot send messages to other students.
Messages behave like chat, meaning that a private conversation starts between a student and all teachers when they send a message.
Here's the ER diagram I made:
So my question is, is this table normalized properly for my purpose? Is there anything that can be done to reduce redundancy of data across my tables? And out of curiosity, is it in BCNF?
Another question: I don't intend to ever implement delete features anywhere in my system. Only "archiving" where said classroom/task/member/message/whatever is simply hidden/deactivated. So is there any reason to actually use FK?
EDIT: Also, a friend brought to my attention that the Conversations table might be redundant, and it kinda feels so. Thoughts?
Thanks.
In response to your emphasis on "modifiability" which I'm taking to mean with respect to application and schema evolution I'm actually going to suggest a fairly extreme solution. Before that some notes some aspects you've mentioned. First, foreign keys represent meaningful constraints in your data. They should always be defined and enforced. Foreign keys are not there just for cascading delete. Second, the Conversations table is arguably redundant. It would make sense if you had a notion of "session" of chat which would correspond to a Conversation. Otherwise, you just have a bunch of messages throughout time. The Conversation table could also enable a many-to-many relation between messages and tasks/exercises if you wanted to have chats that simultaneously covered multiple exercises, for example.
Now for the extreme suggestion. You could use 6NF. In particular, you might look at its incarnation in anchor modeling. The most notable difference in this approach is each attribute is modeled as a different table. 6NF supports temporal databases (supported in anchor modeling via "historized" attributes/ties). This means handling situations like a student being associated to a task now but not later won't cause all their messages to disappear. Most relevant to you, all schema modifications are non-destructive and additive, so no old code breaks when you make a change.
There are downsides. First, it's a bit weird, and in particular anchor modeling (somewhat gratuitously?) introduces a bunch of new terms. Second, it produces weird queries for most relational databases which they may not optimize well. This can sometimes be resolved with materialized views. Third, at the physical level, every attribute is effectively nullable. Finally, the tooling and support, while present, is pretty young. In particular, for MySQL, you may only be "inspired by" what's provided on the anchor modeling site.
As far as the actual database model would go, it would look roughly similar. Anchor modeling uses the term "anchor" for roughly the same thing as an entity, and "tie" for roughly the same thing as a relation. For simplicity, dropping the Conversation relation (and thus directly connecting Message to Task), the image would be similar: you'd have an anchor for Classroom, Member, Message, and Task, and a tie replacing Recipient that you might called ReceivedMessage representing the relation of "member received message message". The attributes on your entities would be attribute nodes. Making the message attribute on the Message anchor historized would allow messages to be edited if desired and support a history of revisions.
One concern I have is that I don't see a Users table which will hold all the students and teachers info (login, email, system id, role, etc) but I assume there is something similar in our system?
Now, looking into the Members table: usually students change classes every semester or so and you don't want last semesters' students to receive new messages. I would suggest the following:
Members
=============
PK member_id
FK class_id
FK user_id
--------------
join_date
leave_date
active
role
The last two fields might be redundant:
active: is an alternative solution if you want to avoid using dates. This will become false when a user stops being member of this class. Since there is not delete feature, the Members entry has to be preserved for archive purposes (and historical log).
role: Depends on how you setup Users table and roles in your system. If a user entry has role field(s) then this is not needed. However, this field allows for the same user to assume different roles in different classes. Example: a 3rd year student, who was a member of this class 2 years ago, is now working as TA/LA (teaching/lab assistant) for the same class. This depends on how the institution works... in my BSc we had the "rule": anyone with grade > 8.5/10 in Java could volunteer to do workshops to other students (using uni's labs). Finally, this field if used as a mask or a constant, allows for roles to be extended (future-proof)
As for FKs I will always suggest using them for data consistency. Things can get really ugly really fast without FKs. The limitations they impose can be worked around and they are usually needed: What is the purpose of archiving a message with sender_id if the sender has been deleted by accident? Also, note that in most systems FKs are indexed which improves the performance of queries/joins.
Hope the above helps and not confuse things :)
new to stackoverflow.
Pretty low level question here I'm sure but I'm designing a relational data model and in several of my tables the case study I'm working from has said that 'postal address' should be stored as an attribute. Not only is this very vague, but surely multi-valued, which the case study states must be resolved. How do I go about splitting this into more specific attributes, baring in mind that of my 5 tables, 3 have at least one address attribute (e.g. correspondence address, term address).
Thanks.
See Database normalization, specifically you need to bring it into the 4th normal form to get rid of the multi-valued dependencies.