I have to write the conceptual diagram of a DBMS.
I have a very simple, maybe banal question, but I found no answers on the internet.
This DBMS will be used by the secretaries of a school. In this schema there are entities like students, courses, exams and so on.
Can I also add the entity "secretary", even if the secretaries will be the ones who will use the DBMS?
Sure your can. You can, and in fact, you should throw everything on your conceptual design whiteboard that has any relevance to your system. And do some contemplation of where the chips might fall.
Usually you would have a "User" in your system, and that "User" might be a "Secretary" but very quickly you have other "Users", which would include the "Students" and possibly "Managers" and "Advisors".
The whole point about a word as general as "Entity" in an Entity-Relationship Model is that it is general and anything whatsoever of interest to your problem can be an "Entity" in that sense.
An entity is a type of thing to store in your database system.
Each different entity type has an identifying key, and a distinct set of attributes. For example, a user entity might have some identification number, and perhaps attributes for login name, password, creation date, email, real name, etc.
Then you have to ask if a secretary is just one of the users, or is it a distinct entity?
The answer is driven by whether a secretary has unique attributes. Is there some fact about each secretary that needs to be stored in the database, that no other user has?
If not, then perhaps secretary is just an example of a user entity. Maybe it would be helpful to make the user entity have an attribute column to note the type of user (secretary, administrator, faculty, parent, etc.), but not create a separate entity unless the category of secretary needs their own attributes.
Related
I was just wondering how the following would be represented in an ER diagram.
Question
Each person is identified by a unique id number OR their full name, which includes first name, middle name, and last name.
This is what I have done so far. This is probably a very easy question, but I am new to database design and any help would be mush appreciated.
Person needs a unique identifier/primary key, whether it is a surrogate, or an ugly concat of ID_FullName. You can keep both and mark them unique (nullable) if there are cases where one is null.
If you really need both then rethink whether you need a supertype like Entity with subTypes of Person and UnamedPerson -- you have to ask yourself why there wouldn't be a UniqueID in all cases for a Person and decide there.
Also consider a more compact representation for ERD's -- there are alot of variants, but most look like this w/ Crows feet as my pref.
Also look for sample ERD's similar to your use case to model off. Person/Entity/Group/Role stuff has common idioms.
I was told to create a ERD diagram given the following
The college keeps track of each student’s name, student number, social security
number, address, phone, date-of-birth, and gender.
– Each programme is described by a programme code, name, description, duration
(number of years), level, and the cost.
– Each module has a module code, name, description, duration (number of weeks),
level (introductory, intermediate, advance).
– Grade stores student number, module code, and a letter grade (A, B, C, D, E, F).
Each program enrolls students. Students then register modules. At the end of the
study duration of a module students receive their grades.
I have made attributes for each entity
Student
(sNmber, SSN, sName, address, phone, DOB, gender)
Programme
(pCode, name, description, duration, level, cost)
Module
(mCode, name, description, duration, level)
Grade
(sNumber, mCode, grade)
My final diagram looks like this with entity relationships as well, I know I will have to break the M:N relationships down to two 1:M ex.
Contains - programme_ Modules (pCode, mCode)
But my diagram seems off with the connecting Modules and Students to grade??
I am very new to this so would really appreciate some pointers
The first thing is, that "schema" is not definitive enough to be called a schema. Although the Keys may be obvious to you, they are not identified. At best, it is a description, and an incomplete one. Eg. if it were a schema, the M::N issue would be resolved, the table would be named, and all Keys would be identified.
In the ERD, you have not shown the attributes, which is required. Next, you need to show which attributes are Keys.
ERD
Here is an ERD, using somewhat improved symbols, erected from your description.
Note the Relational Keys:
They are composites
They are required to:
prevent duplicate rows
enforce Relational Integrity, which is logical (as distinct from Referential Integrity, which is physical)
Such as, we want to constrain a Student to register for a Module that is in the Programme that he is enrolled in.
Relational Data Model
Obviously, the ERD is very limited, it does not have the capability to show all the definitions that are possible, and desired, in a Relational data model. Further, as evidenced, it gets crowded very quickly.
It is quite ridiculous to teach ERD for Relational databases. In the real world, we do not use ERD for modelling data, we use IDEF1X, the Standard for Relational data modelling since 1993. This is what it looks like.
Note • Notation
All my data models are rendered in IDEF1X
My IDEF1X Introduction is essential reading for beginners
Note • Content
The Primary Keys, as well as Alternate Keys, are explicit.
The Level in Module is understood. The Level in Programme is not clear. It may or may not have some relation to the former.
The Predicates can be read directly from the model. If you need them in text form, please ask.
I was studying about relationships in RDBMS.I have understood the basic concept behind mapping relation ship,but I am not able to spot them.
The three possibilities :
one to many(Most common) requires a PK - FK relationsip.Two tables involved
many to many(less common) requires a junction table.Three tables Involved
one to one(very rare). One table involved.
When I begin a project,I am not able to separate the first two conditions and I am not clear in my head.
Examples when I study help for a brief moment,but not when I need to put these principles in to practice.
This is the place where most begineers falter.
How can I spot these relationships.Is there a simpler way?
Don't look at relationships from a technical perspective. Use analogies and real-life examples when trying to envision relationships in your head.
For example, let's say we have a library database.
A library must have books.
M:M
Each Book may have been written by multiple Authors and each Author may have written multiple Books. Thus it is a many-to-many relationship which will reflect into 3 tables in the database.
1:M
Each Book must also have a Publisher, but a Book may only have one Publisher and a Publisher can publish many Books. Thus it is a one-to-many relationship and it reflects with the PublisherId being referenced in the Books table.
A simple analogy like this one explains relationships to their core. When you try to look at them through a technical lens you're only making it harder on yourself. What's actually difficult is applying real world data scenarios when constructing your database.
I think the reason you are not getting the answers that you need is because of the way you are framing the question. Instead of asking “How do I spot the correct type of relationship between entities”, think about “How do my functional needs dictate what relationship to implement”. Database design doesn’t drive the function; it’s the functional needs that drive the relationships you need to implement.
When designing a database structure, you need to identify all the entities. Entities are all the facts that you want to store: lists of things like book titles, invoices, countries, dog species, etc. Then to identify your relationships, you have to consider the types of questions you will want to ask your database. It takes a bit of forward thinking sometimes… just because nobody is asking the question now doesn’t mean that it might not ever be asked. So you can’t ask the universe “what is the relationship between these lists of facts?” because there is no definitive answer. You define the universe… I only want to know answers to these types of questions; therefore I need to use this type of relationship.
Let’s examine an example relation between two common entities: a table of customers and a table of store locations. There is no “correct” way to relate these entities without first defining what you need to know about them. Let’s say you work for a retailer and you want to give a customer a default store designation so they can see products on the website that their local store has in stock. This only requires a one-to-many relationship between a store and the customer. Designing the relationship this way ensures that one store can have many customers as their default and each customer can only have one default store. To implement this relationship is as easy as adding a DefaultStore field to your Customer table as a foreign key that links to the primary key of the Store table.
The same two entities above might have alternate requirements for the relationship definition in a different context. Let’s say that I need to be able to give the customer the opportunity to select a list of favorite stores so that they can query about in stock information about all of them at once. This requires a many-to-many relationship because you want one customer to be able to relate to many stores and each store can also relate to many customers. To implement a many-to-many relationship requires a little more overhead because you will have to create a separate table to define the relationship links, but you get this additional functionality. You might call your relationship table something like CustomerStoreFavorites and would have as its primary key as the combined primary keys from each of the entities: (CustomerID, StoreID). You could also add attributes to the relationship, like possibly a LastOrderDate field to specify the last date that the customer ordered something from a particular store.
You could technically define both types of relationships for the same two entities. As an example: maybe you need to give the customer the option to select a default store, but you also need to be able to record the last date that a customer ordered something from a particular store. You could implement the DefaultStore field on the Customer table with the foreign key to the Store table and also create a relationship table to track all the stores that a customer has ordered from.
If you had some weird situation where every customer had their own store, then you wouldn’t even need to create two tables for your entities because you can fit all the attributes for both the customer and the store into one table.
In short, the way you determine which type of relationship to implement is to ask yourself what questions you will need to ask the database. The way you design it will restrict the relational data you can collect as well as the queries you can ask. If I design a one-to-many relationship from the store to the customer, I won’t be able to ask questions about all the stores that each customer has ordered from unless I can get to that information though other relationships. For example, I could create an entity called "purchases" which has a one-to-many relationship to the customer and store. If each purchase is defined to relate to one customer and one store, now I can query “what stores has this customer ordered from?” In fact with this structure I am able to capture and report on a much richer source of information about all of the customer's purchases at any store. So you also need to consider the context of all the other relationships in your database to decide which relationship to implement between two particular entities.
There is no magic formula, so it just takes practice, experience, and a little creativity. ER Diagrams are a great way to get your design out of your head and onto paper so that you can analyze your design and ensure that you can get the right types of questions answered. There are also a lot of books and resources to learn about database architecture. One good book I learned a lot from was “Database System Concepts” by Abraham Silberschatz and Henry Korth.
Say you have two tables A and B. Consider an entry from A and think of how many entries from B it could possibly be related with at most: only one, or more? Then consider an entry from B and think of how many entries in A it could be related with.
Some examples:
Table A: Mothers, Table B: Children. Each child has only one mother but a mother may have one or more children. Mothers and Children have a one-to-many relationship.
Table A: Doctors, Table B: Patients. Each patient may be visiting one or more doctors and each doctor treats one or more patients. So they have a many-to-many relationship.
An example of one to one:
LicencePlate to Vehicle. One licence plate belongs to one vehicle and one vehicle has one licence plate.
I've been looking through different questions on here and I can't find something that exactly matches my situation.
I am designing a database for multiple types of users. I have one main User table which includes ID, Username, Password, PasswordSalt, AccountType (enum), and LastLoginDate. I need to have multiple types of accounts: Student, Parent, SchoolAdmin, SystemAdmin, Coordinator, and Teacher. I was originally thinking of having a separate table for each of these types of accounts, but I realized that SchoolAdmin, Coordinator, SystemAdmin, and Teacher all share the exact same data. These account types all have different permissions though. The Student and Parent accounts have extra information that they have to store.
I then thought about adding the information that the 4 identical tables share to the User table and then deleting those tables, but I came across another problem. I need to reference different types of accounts in other tables. For example, I had a foreign key for TeacherID in the Club table to show who the club sponsor is. If I add the information to the User table and get rid of those other tables, then how do I reference a specific account type in another table?
I have never designed a database like this so any help is appreciated.
There are three main ways of implementing inheritance on database models. Please check the links below, and study which is the best one to solve your problem. Nothing better to start analyzing this types of situations to become a good architect.
Single Table Inheritance
Class Table Inheritance
Concrete Table Inheritance
Each of the different approaches have their pros and cons so choose wisely.
We have a MySQL database with employees, companies and addresses tables.
The setup works like this: employees and companies each have an id. Since they are in two different tables, an employee can have id = 1 and the company can have id = 1. Both can have multiple addresses.
Now the address table has two columns that links it either to a company or to a employee:
element_id
element_type_id
element_type_id is either 1 = person or 2 = company
The whole thing is a bit more complex and there are many more tables, but that kinda explains the concept.
The problem is now that we would like to start using the Entity Framework and for that we need to define relationships with foreign keys.
But that sounds pretty much impossible with the setup that we currently have, does it?
Since the address table would need to be combined with the person and the company somewhow....
Any ideas?
This concept is known as polymorphic associations. I once asked a question about it, because I had a similar data structure that I wanted to make referentially sound. In terms of this question your Address corresponds with the Comment table and Employee and Company with Person etc.
The answer was excellent. If you can change the schema I would certainly go for it and use that approach.
If you can't change the schema you can always subtype your Address class in your EF model and use element_type_id as the discriminator column. You would create subtypes EmployeeAddress and CompanyAddress, where Employee refers to the former and Company to the latter. But as "the whole thing is a bit more complex" I'm not sure if this will be feasible in your situation.
You already meantioned yourself that this concept is not fitting into a relational database. It is not wrong, MySQL and all the other just don't support it. And it is not a normalized layout, so it might be regarded bad practice by database engineers.
You should think about separating the address from the relation by creating two additional tables: employee_adresses and company_addresses, each holding a relation to the company and the address or the employee and the address. This way you might get one address that is used for a company and many employees, which might be a good thing (normalized structure).