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.
Related
Im getting confused on this day fixing the database for having the consistent field name.
When i want to name the field to explain: the name of the one who locked, or hidden the post.
What's the field should i use?
locked_by_username , lock_by_username or lock_username
hidden_by_username , hide_by_username or hidden_username ?
Present tense or past tense? and should i use by inside the field name, does it a bad practice?
I see many database use post_username or poster_username to describe the username of the one who posted the post.
But with lock and hide verb, i can't see any the good way for describing it.
Sorry, i know this is a really stupid question, but English isn't my native language.
Whether your native language is Kiswahili or Klingon or English, what you want here are column names that describe current state. For example username_holding_lock means the column contains the name of a user holding a lock on the row.
Somebody using a tool to troubleshoot by doing SELECT * will then be able to guess what's up when the value TomSawyer appears on some row.
I think this is more opinion based but I generally would use camel case.
I personally would use:
HiddenByUsername
LockedByUsername
A good idea might be to look at some of the Microsoft sample DB's.
A example would be the AdventureWorksDB or you can look here
http://codeplex.com/SqlServerSamples
I've managed to identify the table from an attribute in SAP Netweaver ERP.
For example, Order Number (AUFNR) comes from table AUFK, and my question is: where do attributes like Material description (MATXT) come from?
I can't found this info via SAP user interface (from the little I know) and when I search on the internet for the structure, this attribute is also unidentifiable.
I post this question because I need to extract data to SQL Server tables, and I can't seem to find the source, via SAP user interface or on the internet. This might be probably a conceptual question about data organization in SAP.
The naming of this field (CO_XXXXX) unequivocally points out that this field relates to CO (Controlling) module, which should have been suggest you the proper direction.
The most probable tables this field can relate to are COCH and COCHP.
However, this fieldname is widely used in Plant Maintenance Notifications (PM-WOC-MN) as well.
Full list of structures and tables where it is used can be obtained in DD03L table. Query by field FIELDNAME, for example, like this, should give you the thing
SELECT *
INTO TABLE #DATA(result)
FROM dd03l As d3
JOIN dd02l AS d2
ON d3~tabname = d2~tabname
WHERE d3~fieldname = 'MATXT'
AND d2~tabclass = 'TRANSP'. << if you want to exclude structures
P.S. Your screenshot is almost unreadable.
Update:
SAP has plenty of modules and their consideration is out of the scope of your question.
Why they should? It is rhetorical question.
If you are nor ABAPer, you can simply use 'MATXT' as search predicate in SE11/SE16/SE16n for table DD03L.
F1 -> Technical Info command should help in finding used structures in most cases, but not in 100% of cases. To identify what tables are used in a transaction is almost impossible without such tools as Debugger, Traces and without ABAP experience.
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 :)
I need to solve a problem within job booking software and am hoping to find a good way of doing that.
The current system uses a set of check boxes to represent the problem description when a customer rings up. These check boxes are useful to admin, but not really from a customer perspective.
My thoughts were to have 1 or more english representations of these checkbox items, corresponding to each one. That would be easily searchable on the fly while a customer was on the phone explaining their problem.
Sometimes the telephone operator may need to ask a further question though, and I will need to allow for a level of questioning after the initial problem description.
At the end of the problem diagnosis, this should still represent 1 or more checkboxes at the back end.
An example:
A customer rings up complaining that "my water is cold".
Telephone operator types in "cold" and multiple results are returned "repair hot water system - gas" & "repair hot water system - electric"
In order to correctly choose, another set of questions is presented for the telephone operator to ask. "Is your HWS Gas?", "Is your HWS Electric?"
Once that is selected, the correct item is associated with the job.
I need to find the best way to represent this?
I guess the core elements are:
The low level checkbox descriptions
The english descriptions (1 or more per checkbox)
The secondary questions to narrow down the description
Any help would be appreciated!
Basically, one question can have multiple answers. Each answer can lead to multiple questions. This can go on for multiple levels. Here is a very basic description of how I would approach tackling this...
Here is a suggested lookup table structure:
table: Questions (QId, QuestionText) all questions are saved here
table: Answers (AId, AnswerValue) all possible answers are here (yes, no, cold, hot, warm, not working, etc)
table: QuestionAnswers (QAId, QId, AId) question answer combinations are stored here (is the ac working? yes / no)
table: RelatedQuestions (QAId, QId) for a given question answer combination, what is the next set of question(s) to ask ("is the ac working - no" then ask "do you have power?, do you have an AC in the house", "is this the car a/c or the home AC?")
Here is a suggested data table structure:
table: CustomerInfo (CuId, CDetails...) one record per customer
table: ContactInfo (CId, Cdetails...) one record each time a customer is contacted
table: QASeriesForContact (QACId, CId, SearchTerm) the search term / issue (you can have multiple of these per call, right?)
table: QASeriesDetails (QASDId, QACId, QAId) for each problem, track the question answers until resolution
I know we are going to have to modify this a fair bit to suit your needs - fire away and I will do my best to help.
Suppose you have two objects, Person and Address and they have a relationship, that is a Person has an address. Obviously the person object has a reference to the address object but does the address object really have to know about the Person object? What gives that it has to be a two way relationship?
Thanks!
In this case it looks like your Address object doesn't need to have a relation to the Person object.
As a rule, you can think whether an object "needs to know" the other in order to work. A Person needs to know its Address, while an Address doesn't need to know the Person it belongs to.
"need to know" here reflects the need to interact with the object in a method.
It all depends on the use of the objects. If you have a situation where you must take an address and show (or use) its person (or persons) it will be a two-way relationship. But if you never need to access a person given an address then you will not need a two way relationship.
Other example: if those objects are associated with database tables and those table have a relationship (say Person.id == Address.IdPerson) then it will be useful to have a two way relationship in the classes for inserts and updates.
The only type of situation I can think of that it would be beneficial is if you had an external reference to an Address and you wanted to know who lived there. Even then, I think a separate associative data structure that maps Address -> Person would be a better design.
Other than that, in the relationship you describe there is no reason it has to be a two-way relationship. There's no rule that says an Address needs a reference to a Person.
They way to think about it is does my object depend on a property to exist. So in this particular scenrio, Person depends on an Address therefore it needs to know about the address details. The Address on the other hand does not depend on the Person hence can exist without knowledge of the Person.
If you need to access the person via the Address I would suggest implementing a function in the Address object that you can call which will retrieve the Person(s) relating to that particular address.
James.
In my opinion the Address object doesn't know about the Person object at all.
If it does then it interduces thight coupling to the system.
If you have to find a Person by it's Address you create a Pepole contianer that has a find method that searches by Address.
An Address doesn't have to know of the existance of Person, I think this is not logic in a real world: an address is just a group of information (say street, town, etc), it can be used by a letter or by a person, but in each case it still remain what it is, without knowing its surroundings.
It should only care of information strictly related to him.
What gives that it has to be a two way
relationship?
The only thing I can come up with that would be a motivation for an Address to know about other objects would be if you are in dire need of caching. Let's say you have some form of application where searches are made all the time. But that's pretty much it.
The complexity of this problem depends on the business domain and what you mean by address. In the majority of systems this is simplified to be a person object who has a relationship to an address object representing where they stay and if two people stay at the same address they address will be duplicated.
If you want to have a more complex real world model then consider changing to terminology to locations (which may even be represented spatially).
Considerations
A person may be related to zero or more locations (consider summer and winter homes)
A location exists regardless of having people related to it
If a person moves home consider changing the relation ( used to live at ) rather than the location. This provides a great deal of flexibility it the future
Multiple people can be related to the same location. This makes it very simple to find everyone who currently (or previously) stayed at a location
Storing locations and relationships provides great flexibility but it comes with an overhead, so you need to decide if your design needs this level of flexibility.