I have to design a database for an advert site.
Until now this is the design i came up with:
Administrator(Id,Name,Password)
Advert(Advert_Id,Title,Description,Category,User,Date_created,Picture,Type)
User(User_Id, Name ,Phone,email,Address)
Category(Cat_id,Cat_Name)
Type(Id,Type_Name)
Picture(Picture_Id,Name)
The administrator refers to to the person that will manage the site.
The type refers to the type of the advert: selling, buying etc.
I must have minimum 5 tables at least 2 one to many relationships and at least one many to many relationship. The problem is that I can't find a many to many relationship that would make sense.
If an advertisement can have more than one category, then advertisements and category would be many to many.
If an ad can have more than one picture and a picture can be used in more than one ad, ads and pictures would be many to many.
However, you have to know the business rules. None of us will.
Like Dan mentioned on the answer, you have to know the Business Rules. It's a project for a class, so the business rules might be flexible, I remember back in college, for example, they would tell us that if a client wanted to have advertisement be of at least one category, but could have up to 3 or 4 different categories, that changes your DB structure a lot.
An advertisement can also have many pictures, not just one. It can even have some videos, and many of them as well. Make sure you clarify well the Business Rules and that you understand them fully, as in a real life situation, that can represent either the success of your project or the failure of it.
Related
Quick question about an ER/EER Diagram.
I have made this Entity Relationship Diagram, but I have been told, that there is something wrong with it by a friend. Is there something wrong with it?
The ER diagram is a design of a Library Management System, where a member can borrow 5 books at a time. The rest of the functionality of the system is how a normal library functions.
Library Management System EER
i don't understand the utility of the relationship between the librarian and the card and i don't understand why the books are splitted in two entities.
I would do 3 entities:
-member
-card
-book
every member has one card, every card is of one member;
every member can take many books, every book can be taken by many members,
the relation between member and book create another table in the logic schema: loans. before inserting a new loan you can check if the member has alredy 5 active loans (by checking the attribute active in the loans table).
Your given context is incomplete for me. I do not see the whole description of your problem/situation, so I will answer based on assumptions, and the experience I had during my life. So let's see...
The tino user questioned the existence of two entities, title and volume, which is something important. Let me explain this for a moment, which will eliminate this as an error. Previously (a time ago) we had video rental stores (I don't know if this the right name where you live, english is not my native language). Remember? We used to go there to rent VHS tapes to watch at home.
What we rented were not films, but more copies/midia of them. A film will always have the same actor, director, title, etc., but a copy could have different attributes/properties, like the year that the media was manufactured, the available languages, the expiration year, among other things. So we had distinctly two different things.
But despite this, we have to consider whether there is a need to create two entities for persistence. We have to remember if we need to persist this information. If a copy/midia has no attributes, then it's entity should not exist, and what a user would rent really would be the movies titles.
In your case, the relationship between volume and title, I belive, is really expressing this discrepancy.
Let's talk about the relationship between librarian and title. What a librarian manages? Does It manages the titles that never change and are abstract things, or the physical objects present in the library? :)
Finally, let's talk about the borrows relationship. When we break down 1-N (or N-1) relationships, we always pass the primary key from the 1 side to the N side, solving the relationship to the formation of the Physical Model in a Entity-Relationship Diagram.
Despite this relationship here is a 0-5, to decompose it, we will not have exactly a 0-5 relationship. We would have in anyway to pass the primary key from the two sides to the table formed by this relationship. Therefore, here we have initially a N-N relationship between member and volume.
N-N relationships allow optional relations between entities. This means we can have the zero side cardinality here. To limit the number of books that can be rented, you need to implement a restriction/constraint with SQL, or with any procedural language in your database. In this case, you can implement a before insert trigger. This trigger has a duty to verify this restriction to allow or denny the completion of the operation as a whole.
Let it be clear that I'm not saying you should remove this notation. Your Conceptual Model should express it. But when you are decomposing, you have to remember that. I think you should just correct it.
Remember one important rule: Relations that have attributes/properties (the attributes/properties) can only exist in N-N relationships. If you have to put attributes/properties in a 1-N (or a N-1) relation, they (the attributes/properties) will always be on the N side. In summary, there are no N-1 (or 1-N) relationships with attributes in the relation. Only N-N relations can have attributes/properties. So be careful with this.
Any questions or clarification, please comment and I will answer.
I see no reason to distinguish member and card. Volume and Librarian don't have primary keys. Are they supposed to be weak entities? That doesn't make sense for Librarian and Volume needs an identifier to distinguish different copies.
I'm new to database design and have some uncertainties about how best to model this particular case. I'd appreciate any suggestions for this fairly simple scenario.
When a production task begins, two people are involved at all times. One is in charge of the production, and a second is tasked with quality assurance. For any task in the database, it must be possible to identify these two people. They'll both exist in a Person table and have IDs, so I just want the best way to relate them to the production task. The following rules exist:
Either person may be swapped out for a different person at any time.
Each task always involves both people (Neither of these are null).
There are never any other people involved in the task that we want to record.
Each person may be involved in multiple tasks, or none at all.
If we had a whole host of relationships between the task and the people, I'd create some sort of convoluted relationship structure describing their relationship (As producer, quality assurance person, overseer, etc.), but here I feel as though it's sensible to just stick the IDs of the two people in the Task table, in separate columns for Production Person and Quality Assurance Person. Is this bad for some reason that I can't see?
What has really prompted my question is that I'm trying to design exactly that in DBDesigner 4, which I'm new to, and it just doesn't like it - When I try to set up a second non-identifying relationship between Task and Person, it won't give me a second field. It also won't seem to let me rename the fields in Task that refer to the persons, so it'd be impossible to differentiate between the two anyway. Since no-one else seems to share this problem, I've began to wonder whether it's a good idea at all. Is it standard to introduce additional tables as soon as there are two or more links between two entities? What would that look like if I wanted to enforce the above rules? I can't see how I'd ensure that an n:m table always has entries for both people working on the task.
If you are confident your requirements will stay this rigid forever, then just create two NOT NULL FKs:
This declaratively enforces that exactly two people are associated to the task at all times, which would not be readily achievable with just the junction table (as you already noted).
OTOH, if you anticipate your requirements might change at some point in the future, then the added flexibility of junction table might be more important than the completely declarative enforcement of your business rules.
I'm not familiar with DBDesigner, and therefore with your particular problem, but in ER modeling in general, multiple relationships with the same entity are distinguished by their "rolenames" which determine the names of migrated attributes (see the section on "Rolenames" in the chapter 3 of the ERwin Methods Guide). Try locating something along those lines in the UI of your tool.
If you want to know the current state and not who held the role previously #Branko Dimitrijevic's solution will work.
But if the statement 'Either person may be swapped out for a different person at any time' implies you need to know who previously held that role consider a 3 table design
Task; TaskID, <other details>
Assignee; TaskID, PeopleID, role, start_date, end_date
People; PeopleID, <other details>
Then in the assignee table you need constraints to ensure that for each TaskID, Role combination the dates are reasonable e.g. dates don't overlap or have gaps. That you have only 1 of each role active for each task at a time. To manage this would probably require code either in triggers or the application.
I asked the following question on a database site:
I am trying to build an EER Model for a Autostore that has 5 locations
and offers a range of auto products. They offer car repairs and
roadworthy tests as a service also. I need to be able to make
fortnightly reports on unfinished service jobs, and fortnightly
reports on the sales. They have a wide customer database filled with
full addresses. There is a constant inflow of new stock items and
restocking of old ones. There should also be a way to know the cost of
each item in stock and where its being held.
I swear I've researched it enough to be able to understand it by now
but Im really struggling to map this out as I'm constantly running
into a wall when dealing with the products that are being restocked,
sold and stocked by particular stores in different locations.
-I'm a total rookie with this kind of thing but if anyone can help me it would be amazing.
but I am struggling to find an answer and was thinking that maybe if I asked someone here to build an SQL setup it would lead me in the direction of being able to make the model or if there was a way of building the relational model then it would be a simple step from there, unless someone has the original answer - or all of them haha, hope you can help!
Thanks,
Jacob
If you are struggling with creating an EER diagram, my guess is that you may not have captured detailed enough requirements for the application. A clear understanding of the functionality the application should provide should lay the groundwork for what you need to model in the database.
Ask yourself these questions.
Have I created user profiles for each type of user the application will be used by?
Have I outlined every action these users will be performing on the application and the details of the actions?
These are just two of many questions that you have hopefully fully addressed. If you have addressed these topics and everything else fully, perhaps you just need a different approach in organizing your requirements.
Break it up into segments of data. For example, you'll need to create a system of tables that manages inventory. Which will need to then be linked up to a system of tables that manages sales and service records. Which will need to be linked to a system of tables that manages customers data. The sales/service and inventory control will need to be linked up to a system of tables that governs employees and their roles and ability to do things (security, privileges, etc). I can go on and on speaking theoretically about this, but this should hopefully be enough to get you started.
Good luck.
I'm developing an e-commerce site and I'm facing a problem. The requirement I need to fulfill is: given a certain string like "lock", "tennis", "cinema" or "scaffold" entered by an user, I should display both profiles and product postings matching that query.
That leads me to these conclusions:
a) I should classify profiles (what they do): maybe some sort of "business category". I face a problem here, it's almost impossible to create a list that covers all the business activities in the world, so I've been reading some good questions here and liked the strategy of creating a 1 or 2 level hierarchy and then capture the user feedback automatically through reusable tags.
The idea here is to keep the keywords that are more likely to be thought of and so with best odds of being searched for.
By the way, is there a really good business category list out there that I'm missing?
b) I should classify products and services (what they offer): with a similar approach, I liked using some fixed categories and then let users use persistent tags. I ask you again if there is a category list out there that really rocks.
Questions:
1) Do you like what I've just described? Based on your experiences do you think it might work or will I drown in a tag sea?
2) Sometimes both product and business hierarchies are kind of redundant. There are some people that describe their businesses like "theater", "bank", "dentist" and that's not a product or service but rather what they actually are. But there are plenty of cases where people say "(sale/manufacturing) cars", "(manufacturing) pottery", and so on. Their business activity is chiefly determined by the product or service they're selling or producing. What's your take on this?
I did something like this is ror_ecommerce. I used a tree for product_types.
So you could sell:
Furniture => Livingroom => Chairs
Filtering by Livingroom would also give items that have a product_type pointing to Chairs.
To make it more complex I would first fight the business person.
Second I would create a model where product has many product_types. Thus you need a join table between product_type and product.
Answer to your question:
1) You will probably drown because categories are infinite. Limit the number of tags or make an admin interface that your business people can populate. If not your business folks will request you to do this work over and over again.
2) It sounds like Your tree would look like this:
sale/manufacturing => cars
sale/manufacturing => pottery
bank => personal
bank => business
thus if someone just wants a bank they get results for personal and business. but they can further refine the search to just personal banking.
It also sounds like the business and product hierarchies are completely redundant. I would really fight a business guy saying anything else because a future requirement will be to relate business and personal hierarchies. If they are the same it will be easy. You might want a type flag on the list for personal / business / both. it will be a lot easier to remove the flag if it's not needed.
Good Luck
Update Edited to reflect clarifications requested by Chris Holmes below. Originally I was referring to a Terminal as a Site but changed it to better reflect my actual domain.
At heart, I think this is a question about modeling a many to many relationship between two root entities where the relationship itself carries some semantic meaning.
In my domain
You can think of a Terminal as a branch location of our company
A Terminal can have a relationship with any number of customers
A customer can have a relationship with any number of terminals (standard many to many)
A customer\terminal relationship means that a customer can potentially store products at the Terminal
This relationship can be enabled\disabled. To be disabled merely means you are temporarily not allowed to store product, so a disabled relationship is different from no relationship at all.
A customer can have many Offices
A Terminal that has a relationship with a customer (enabled or not) must have a default office for that customer that they communicate with
There are some default settings that are applied to all transactions between a Customer and a Terminal, these are set up on a Terminal-Customer Relationship level
I think my objects here are pretty clear, Terminal, Customer, Office, and TerminalCustomerRelationship (since there is information being stored specifically about the relationship such as whether it is enabled, default office, ad default settings). Through multiple refactorings I have determined that both Terminal and Customer should probably be aggregate roots. This leaves me with the question of how to design my TerminalCustomerRelationship object to relate the two.
I suppose I could make the traversal from Terminal to TerminalCustomerRelationship unidirectional toward the relationship but I don't know how to break the relation from the relationship to the customer, especially since it needs to contain a reference to an Office which has a relationship to a Customer.
I'm new to this stuff and while most of DDD makes perfect sense I'm getting confused and need a fresh outlook. Can someone give me their opinion on how to deal with this situation?
Please note that I say Relationship not relation. In my current view it deserves to be an object in the same way that a Marriage would be an object in an application for a wedding chapel. Its most visible purpose is that it relates two objects, but it has other properties that rightfully belong to it as well.
By your description, you definitely need a "TerminalCustomerRelationship" entity to track the associated information. I would also convert the 'IsEnabled' flag into a first class 'Event' entity with a timestamp - this gives you the ability to save a history of the state changes (a more realistic view of what's happening in the domain.)
Here's a sample application (in VS2008) that refects your problem. You can tweak/test the code until the relationships make sense. Run "bin/debug/TerminalSampleApp.exe" and right-click "Terminal->Create Example" to get started.
Let me know if you find it useful.
Names can often clarify an object's responsibilities and bring a domain model into focus.
I am unclear what a Site is and that makes the entire model confusing, which makes it difficult for me to offer better advice. If a Site were a Vendor, for instance, then it would be easy to rename SiteCustomerRelationship as a Contract. In that context it makes perfect sense for Contract to be its own entity, and have the the model look like Vendor-Contract-Customer-Office.
There are other ways to look at this as well. Udi has a decent post on this sort of many-to-many relationship here.
You should not have a object Like SiteCustomerRelationship, its DB specific.
If its truly DDD you should have a Relation like:
Aggregate<Site> Customer.Site
IEnumerable<Aggregate<Office>> Customer.Offices
and perhaps
Aggregate<Office> Customer.DefaultOffice