Currently, a hotel is managed by a single manager only. A manager can manage 0 to many hotels, as shown in the below diagram (unfortunately I can't post pictures yet, however I have provided the links:
https://postimg.cc/nXJtL2n5
Now there is a change such that some hotels will be managed by multiple managers, and others will still be managed by a single manager. For example, a hotel used to have a single manager, now it has a bookings manager, a cleaning manager, and a maintenance manager. I want all of these manager roles to appear in the HOTEL entity.
The below image is what I have so far.
https://postimg.cc/mzDP5RqQ
Is there a way to link the hotel with the new manager roles?
Any help is appreciated.
Cheers.
You need to create a separate entity for each of the managers e.g booking, cleaning and maintenance manager as a seperate entity; and then depict the 1:M relationships with the manager and hotels that they are managing. As a PK you need to have a unique key for each of those entitys so you can show the FK in the table they are referencing.
You want to avoid having M:M relationship so they need to be broken down to achieve redundancy in your final database design.
Related
I have a simple and probably. banal question. I am working on the first, conceptual phase of an entity-relationship diagram.
This DABMS will be used by some Managers, that will control (registrate and modify accounts) of customers.
In my diagram I have the two entities "MANAGER" and "CUSTOMER". Is it necessary to connect them with a relationship (M:N), to specify that the Managers are those who will manage the customers' account, or this relationship is unnecessary?
to specify that the Managers are those who will manage the customers
No. ER diagrams typically show relations that are reflected in your database.
Example, what would be visible in your ERD
Each customer has a manager assigned who's responsible for this customer => 1:n - each customer has one manager but one manager can be responsible for multible customers.
Problem Description
Lets say that we need a database to keep many information portals where each portal is independent so it has its own business rules and, consequently, its own "child" tables. For example:
Protocol portal: protocols, phases, flows.
Employee portal: employees, vacations, payslips.
Student portal: students, projects, disciplines.
If we just give regular name to tables, I would get hard to say from which portal it belongs to. For example:
activity table belongs to?
At first glance, I imagined to put a prefix on every table then it would be easy to distinguish inheritance visually.
stu_activity table belongs to student portal.
Soon after, I realized that using this convention, tables could stays with dubious names if another portal has the same prefix. To fix it now, the tables could receive really large (boring) names...
student_activity
student_activity_type
Question
How to properly name each table that belongs to a "parent" portal?
I'm designing the database schema for a CRM. It has the following tables: users, organizations, contacts, addresses, organization_types.
organizations might be a company, a non-profit or a individual.
users have a many to many relationship with organizations. The reason is because one company, for example, can have a salesman and a manager on the app with two different logins. On the other hand, there is the possibility that a salesman is doing sales for two different companies.
contact and addresses have a one to one relationship with organizations. My client only want a organization to have one of each of those.
I designed it in a way that a organization can also be a client, that would belong to another organization. That would mean that the organization table had a one to many relationship with itself.
That made sense to me because they seem to be the same entity. A client will also need a contacts and addresses table and it could also be a company, non-profit or individual.
The point to consider that another developer raised is that with time, it would be expensive to query the database to differentiate organizations that are our clients from the ones that are clients from our clients.
What is the best approach? Would it be better the make a client_organizations table and separate those two?
I will keep one table and create a column named parent_organization. Parent_organization will be nullable and store primary key of parent organization that child organizations belong to
Is it good idea to have database structure like this? Where in manager table id_item is like foregn key from school or company based on the type of the profile (id_item is school.id or company.id based on type field) Like dynamic variable in programming languages where it don't have a type.
Well why don't you create an organization table and reference it to the manager. Do you need this level of detail, having two separate entities?
A manager manages one or more organization.
An organization is managed by only one manager.
An organization can be a company or school.
A school has a location as addition.
The following screenshot is ERD for one application or one business. If you have used QuickBooks youll know that it has starting form called company so in one application we can create many companies and maintain company accounts
if I add a column companyid to all table then I can add many companies in one application
what is the good practice:
Adding company key and exacting company info with company key
Creating database for each company if thrs 100 companies 100 mysql databases
please advice !
Creating a separate database per company is almost assuredly not what you want to do (unless you have a really good reason to need to do so). Adding a company_id to your tables and ensuring that columns you query against are indexed with company_id along with whatever other column you will typically be querying would be wise.
You'll also need to ensure that your application is designed to correctly inadvertent (or purposeful) access from one company to another company's data.
EDIT - Now that I see your ERD has been added: I would add a "company" table containing a company_id, name, and whatever other data you like, then ensure your other tables have an additional company_id field as well.
Since you want to maintain all companies' businesses and accounts within the same application, then there is no need to create a database for each company, just add a Companies table, then add a foreign key company_id to the other database tables