Quick Summary: I'm building an ERD diagram and got lost in connecting two tables.
Introduction:
I'm building an ERD diagram for my project. Idea is pretty straight forward: I can type information about the company and it will be saved in the database. Later, I can see the list of submitted companies, as a list. As of now, I've information on the "paper", which I've implemented into my ERD diagram, so that later I can tell database, what exactly must be saved and where.
I have a primary table "Company_Info" which stores all the information about the company in the database. Using common sense (or not :)) I've created "Foreign Tables" that would store information about the company: "Gallery Images", "Opening_hours", etc. This way I believe, the database would more or less clear and readable by others.
ERD Diagram with the Description of all relationships
Problem Statement
The idea was to create a simple gallery for the company, so that they can upload their Product-pictures. If it's possible I would like to talk about the relationship between the Gallery and the Company tables. The way I see it, I think it should be like this:
One company can have 0,1,2 or many images. (Gallery_Images Table)
Images must be assigned to only 1 company. (Company_Info Table)
The relationship is one mandatory to many optional. (Many images & one company)
Question: I think the relationship between the Gallery_Table and Company_Info table will not work. Reason: Wrong relationship. I'm confused about the connection between those two tables.
I have made a connection via company PK & FK. This way, I think, the database would know what images belong to that specific company.
Confusion is with gallery_id in Gallery_Images table. Shouldn't it be connected with the company_info table too?
Image(BLOB) is a repeating group in Gallery_Images. This is not a problem if your purpose is to draw a diagram of an ER model.
If your purpose is to draw a diagram of a relational model, then the repeating group is a departure from First Normal Form. Relational schemas that depart from 1NF are generally subject to terrible problems, both with regard to performance and with regard to data management itself.
I don't see the Gallery table in your diagram. Did I miss something?
Related
I am new to Dataverse, moving from the SQL Server world, and just created my first Dataverse table (Standard table). Upon creation, the table has lots of what I assume are automatically-added columns? These include "Owner", "Status", "Version Number". I come from the SQL Server background where new tables come "empty", with no columns. I do not think I need these automatically-added columns (this is just going to be a small log table that holds datetime, action, etc. columns).
Would it break anything if these automatically-added columns were deleted? Also, if anyone could provide information about why these columns are included, that would help. I have researched these questions online, but found very little. Thank you in advance.
They are standard, out of the box attributes that you can't remove.
You can change the Ownership within the Table Type to "Organization" when creating the table to remove the Owner however the rest are created as part of every table.
There is some high level detail on the docs
https://learn.microsoft.com/en-us/powerapps/maker/data-platform/entity-overview
Dataverse (earlier called as Common Data service) is Dynamics CRM under the hood. It’s a SaaS model CRM online software comes with some basic fundamental components.
When you create a table (entity) it comes with columns (attributes), relationships, views, forms, dashboards, etc.
The UCI model driven app can be made quickly to include these components with all CRUD operations without any code by doing simple configuration and customization.
To support these barebone functionalities - the necessary attributes like name, currency, statecode, statuscode, createdby, createdon, modifiedby, modifiedon and security implication fields like owner, owning business unit, owning team and change tracking & concurrency fields like row version, etc will be created.
You can keep them aside as they are part of platform and do your customization as you need.
I design my firebase structure and I'm not sure if that the right way.
Little information:
Each college has some departments.
Each departments has many courses.Courses can belong to several departments.
Each Course has some lessons. lesson can be belong to one course.
I have node of courses with all key courses and information
I have node of departments with all departments and informations.
I have node Course_Departments and Departments_courses
in addition I have courses_lectures and courses_lectures
for display each course learn by some lecturers and each lecturers teach some courses.
so my questions are:
1.How I connect the lesson to these table for example? I want to find all the lessons of the course_key1 that lecture_key2 teach?
2. using with many tables in this way can be take many time to get the data?
for UI I don't want to users to wait much for the data.
Looking at your design, I think, you are on the right track.
I'll give some possible hints of what you can take care of. When designing the structure of a Firebase database design rules of non-relational databases should be kept in mind.
One of them is denormalization. Keep the hierarchy flat! That's an important performance factor for data change listeners since all subnodes are involved. That's what you've done so far.
Relationship of entities can be achied by using the keys. Exactly as you did it in the Courses_Department node. The built-in creation of keys should be used. They should be universally unique.
Here's a good explanation when coming from relational databases.
There are 3 entities:
vehicle_model
vehicle
extra_options (such as open top, leather seats, etc..)
Vehicle model can have a subset of the extra options.
Vehicle can have a subset of it's model extras.
I've been trying hours to figure out how to represent this as er diagram, but without success. I Thought about ternary relationship ,and although I don't understand it completely I think this isn't the way.
I thought about creating another 2 entities, model_ext & vehicle_ext ,so that vehicle_ext would be connected to model_ext but this isn't a good design.
This is my first er diagram design. I'm really lost (read er-diagram chapter in "Silberschatz, Database System Concepts" three times already) so any idea would be appreciated.
did you try adding a new table say 'vehicle_vehicle_model_extra_options_map'? (you can name this table to any thing short, but for better explanation i use __map as a standard way for defining the map tables.)
note those two null able foreign key columns in this table.
Basically, vehicle has one to many relation to extra_options, and vehicle_model has one to many relation to extra_options table, therefore the new table was added.
updated:
I’m absolutely stumped by what I suspect is probably simple for those experienced with Access. I’m brand new to Access (2010) and studying a lot, but unfortunately still confused by many basic concepts. I’m embarrassed to admit that I have spent about 40 hours trying (unsuccessfully) to solve the specific issue below. Please forgive me if I haven’t included enough detail here - I’m not sure how much someone needs to know to address this. I’m happy to edit and/or provide more information.
My question:
How do I create a Form for creating new records / editing existing records in Table1 where two fields in Table1 have different values from a single field in Table2? (I have better detail below)
I want the Form to have all the records from Table1. I have tried many different ways with queries, sub-forms, etc., but can’t pull it off. I’m fairly certain the issue is related to how I address Table2. Ideally, the user would be able to select from dropdowns in the form for the two fields to be updated in Table1.
I am including screenshots of a mockup of my intended Form concept, the object Relationships as I currently have them, the design and datasheet views of Table1 and the design and datasheet views of Table2.
“Table1” above is “t_PEOPLE” in the images while “Table2” is “t_COLORS.”
The object relationship types are currently one-to-many with enforced referential integrity (cascade update related fields) and the join properties are "include ALL records from 't_PEOPLE' and only those records from 't_COLORS' where the joined fields are equal."
I'm happy to send the actual database file if that helps.
I will be very grateful for any guidance - thank you!!
The general approach to this is as follows:
A) If I understand what you're trying to do here, your t_colors table is usually referred to as a Reference table or Lookup table. You need to make one form to add, edit, and delete records in this t_colors table. How the user accesses that form varies. I'll get to that in a minute.
B) The form for your People table needs to have drop down menus for your two color selections. In the dropdown menus' RowSource, you will use a query that looks up values in your t_colors table.
C) Depending what you are using your colors for in t_people, you should consider making a third table with PeopleID and ColorID in it. It would then link to both t_people and t_colors. This would allow you to have multiple colors specified for a single person, and you wouldn't be limited to two. In your People form, you would use a subform for these colors. The subform would probably need to be a datasheet form or a continuous form. If you are using a datasheet form for your people form, then you would need to use a datasheet form for the colors subform.
If the user wants to use a color that isn't already in your t_colors table, you need to give them a way of inserting that color. There are various approaches to this. You could use a union query in the dropdowns RowSource that shows a "" option. If selected you would bring up your Colors form and when they close the colors form you have to requery your dropdown menu. Or you could insert the color for them using VBA when they enter a value that is "Not In List" (an event that Combobox's have).
Please note that the relationships you've defined are not overly helpful or important in this case. Yes, they can be helpful when it comes to using the Update Cascade or Delete Cascade features. But quite truthfully, relationships are basically for programmers, to make sure you get an error if and when referential integrity is violated. Users should never see these errors and properly designed forms will prevent them from occurring. The main reason to use them is that it will force you to design your forms properly by giving you an error when something is wrong, hopefully during your own testing phase of the project.
I'm fairly new to Access.
I have a DB table that needs to be normalized. I have some information about a person. These people are authorized to grant access to areas at our work site. Every person may be authorized several times to manage different areas, and of course different people can be authorized to manage different areas. My first try at it was to include the authorization and the areas together, but I realized that I was really repeating the data that way. After doing some study I decided that the best way to do this was to create 4 tables
tblPerson, tblPermission, tblArea, tblArea_Permission
The tblArea_Permission is a join table for the many-to-many relationship between tblPermission and tblArea (this is something that I just learned about). I seemingly set up the table relationships OK on the relationship tab. I also use a query for adding the records to the join table. When I try to do this, with a query that is getting the records from the tables, I get "You cannot add or change a record because a related record is required in table XXX." This would seem to be impossible.
I decided that I could probably live with the DB not enforcing referential integrity and took that away and used a combined primary key for the two records because every person with permission will control an area in only one combination. That seemed to work, but then I noticed that the records would randomly change. I decided that the DB must be corrupt. Parts of the DB seem to be working correctly, so I started with a new database and imported the tables and one form, then started to rebuild the new tables as described above. I got the same error.
Any help would be greatly appreciated. I've read through some different books, and used google, but nothing addresses this.
If a person is authorised to manage an area, you need a persons_area table:
PersonID ) Primary key
AreaID )
Which shows which areas the person can manage. I am not sure where the permissions table is coming from.
You will then not be able to add a record to person_areas table unless you have an ID in the area table and an ID in the persons table. If either of these IDs are missing, you will get the error above.
If you want more relevant comments on your DB design, you will need to post schemas.