So I am building a database for a police station in access. I have a reports super-class that is divided into several sub-classes.From what my books tell me the supper-class should be the one with the "ID" that is the primary key
and that the ID should be passed onto the sub classes so that there are no 2 sub-classes with the same ID .How do I make a validation rule that doesn't allow to make a new sub-clas report if that ID doesn't exists or is being used by other sub classes
There is no way insertion in a table can check whether that primary key is present in another table apart from either forcing this constraint through business rule or by using DB Trigger.
You need to analyse your DB Model again and try to identify a good design.
Related
I'm building a new DB using MySQL to store lessons learned across a variety of projects. When we talk about this in the office, we refer to lessons by the Project Number and Lesson Number, i.e. PR12-81, where PR12 refers to the project and 81 refers to the specific lesson within that project. I want the primary key in my DB to have a hyphen in it as well.
When defining a composite key in SQL, I can make it reference the project and lesson but without the hyphen, i.e. PR1281. I've also considered creating a separate column of data type CHAR(1), putting a hyphen in every row and delcaring that the PK is made of 3 columns.
Is there another way that I can specify the primary key to be formatted in the preferred way?
Let your table's primary key be a nonsensical auto-increment number with no "meaning" whatsoever. Then, within that table, define two columns: project_number and lesson_number. If the two need to be unique, define a UNIQUE index encompassing the two fields.
Don't(!) create database keys which embed information into them, even if the business does so. If the business needs to refer to strings like PR12, so be it ... create a column to store the appropriate value, or use a one-to-many table. Use indexes as needed to enforce uniqueness.
Notice(!) that I've now described four columns:
The auto-increment based "actual" primary key, which contains no information.
The project_number column, probably a foreign key to a projects table.
Ditto the lesson_number. (With a UNIQUE composite index if needed.)
The column (or table) which contains "the string that the business uses."
Over time, business practices do change. And someday you just might .. no, you will... ... encounter a "business-used string" that was incorrectly assigned by the human-beings who do such things! Your database design needs to gracefully handle this. The schema I've described is so-called third-normal form. Do a Google-search on "normal forms" if you haven't already.
I was unable to find a clear answer of how to create an IS_A relationship in Access.
There was the same question here, but without a concise answer:
IS_A relationship primary key validation rules
I have the entity Employee, and two sub-entities Loan_Officer and Branch_Manager. It's a school example of an IS_A relationship really.
I've managed to create A relationship, but there needs to be a constraint that an employee must be either a Loan Officer or a Branch Manager, but can not be both. Now, I can't figure out how to do this, because what ever I do, I can assign the same Employee_ID in both sub-entity tables at once.
I've connected the tables via the PK, as it's shown here:
Now, this table design is just something I've done, in order to be able to connect them via a one-to-one relationship. I had to set the PK of Loan_Officer to "Number" and not "AutoNumber", in order to be able to connect them. The other option is to have a separate PK in Loan_Officer, like "Loan_Officer_ID", and a foreign key, "Employee_ID" in the Loan_Officer table, but the results are again the same (also according to the ER Diagram, the sub-entities don't have a separate PK).
You can't. This is not a feature of the Access database.
You can create CHECK constraints to check for such conditions, but those don't offer features to cascade operations.
See this answer for an example on how to create a CHECK constraint.
There is no such thing as an 'Is A' relationship in databases between tables. This is instead a field in the Employee table or Employee History Table.
The issue of 'can't be both' is a matter of validation logic. Where this validation logic is applied is probably at the form object level (during data entry), not the table level (no data should ever be entered directly into tables by end users).
Look into Access Data Macros . They can be used like SQL triggers firing off when a record is INSERTed, UPDATEed, DELETEed etc.
Consider a simple situation in which there are 2 tables, named Users and WorkGroups.
A User's email address is the primary key in the users table.
A Workgroup_id is the primary key in the WorkGroup table.
A user can create multiple workgroups.
A user can be part of just 1 workgroup.
Under this given scenario I need to track which user created a workgroup.
What I have already done:
Have a variable named workgroup_id in the users table to know which workgroup the user belongs to. This is a foreign key to the workgroup_id in the Workgroup table.
Have a variable named user_email in the workgroup table to track which user created the workgroup. This is a foreign key to the user_email in the users table.
The problem which I am facing here is that this results in a cyclic reference between the users and the workgroups table. Since cyclic references anywhere in programming are a big no no.
How do I solve this? Is there a better design pattern which I am missing here?
EDIT:
As for whether the "circular references are a big no no" or not, conceptually they may not be but since there implementation is non universal in different databases, they still remain a valid problem. This is aggravated by the case when you have use an ORM, where the ORM support for your database limits the kind of database design you can have.
You need to allow at least one of the foreign keys to be NULL. This will allow you to create the first row in that table, leaving the foreign key empty as a placeholder. After you create the corresponding row on the other table, you update the foreign key in the first row.
You could also decide that this is OK as a permanent condition. If you create the first workgroup automatically before creating any users, that first workgroup doesn't really have a creator, so you could leave it set to NULL.
I want to design a database for e-learning. Here is the case.
"Each subject has 2 hierarchy i.e. ScoringComponent and Competency.Each hierarchy is updated every period. Each hierarchy has unlimited depth-level. The lowest level of the ScoringComponent should be mapped to one or more lowest level of competency hierarchy."Relation between the ScoringComponent and Competency Image
Based on the case, i tried to design the database. The result is like Database Design.
The issue in the database design is the multiple Foreign Key for Year-Period Attributes.
From this issue, i want to create the table without Foreign Key and handle the data validity in the application code.
Is it okay for me to remove the Foreign key from the table? and is there any suggestion for my case?
Thank you.
I would not move away from using a foreign key in your table, if you need it.
Are you the only one that will know how the data is arranged in the database?
I am creating a database for a website. It should contain information about a company, information about cases that companies create and finally reports that companies make for the cases.
I have the following objects:
Companies
Cases
Reports
For these objects I have the following requirements:
A company has an id which is unique.
A case has an id. It belongs to a company and it is unique in that context.
A report has an id. It belongs to a case and it is unique in that context.
One company can have Many cases.
One case can have Many reports.
I have tried to model this using MySQL Workbench:
I made a many-to-one identifying relationship between case and company, because cases uniquely belong to companies. I made a many-to-one relationship between report and case, because reports uniquely belong to cases.
How can I model this, in a simple way, such that two companies can have a case each with the same id but otherwise different? And furthermore, a single company can't have two cases with the same id.
There are two ways.
One, you could have a multiple column primary key. This is essentially the way you have it now.
Two, you could create a surrogate key--a made up value which uniquely identifies each row. Most databases can generate these automatically, starting with 1 and incrementing for each new row. You would then add constraints to enforce your business logic. A surrogate key is nice because it is always simple and if your logic or business rules change then you don't have to completely redesign your table, just change your constraints. The discussion of when you should use a surrogate key and when you should use a natural (already existent data) key is long, but boils down to those two points--if a natural key would be complicated or if business logic is likely to change.
If you switch to a surrogate key, your primary key for case will become a simple integer, the case_company_id column in report would be redundant, and the primary key for report would also only be a simple integer.