It's been a long time since I have designed a DB as a Database Diagram but the higher ups want to see it. I have totally become confused because I am a coder, not a DBA.
I have a main table which contains user id, name, username, password, etc. This main table has the primary key of ID. Should sub tables (such as address, phone, etc) have a key point toward the id of the primary user table or should it be the other way around?
yes the yellow key will be at the primary key table...so if you have 3 foreign key tables then 3 yellow pk icons will be at the primary key table the fk tables will have icons that look like a number 8
example
The tip of the key points to the parent table (the one with the "ONE" in a one-to-many relationship) and the round end with the line goes to the child (many) table.
RE:
Its been a long time since I have
designed a DB as a Database Diagram
...
this GUI crap is messing with my style
You can generate a database diagram from an existing database so just design it however you normally would and add the appropriate FK constraints then generate the diagram afterwards.
SQL Server's Database Diagram tool is not very good. One of its many disadvantages is that it doesn't use any of the standard notations for database diagrams. The daft picture syntax it uses is unique to Microsoft. As well as being non-standard it's also particularly useless as a pictorial language because it hides so much useful information - for instance it doesn't identify foreign key columns or optionality or alternate keys. I would strongly recommend you invest in a better tool if you are serious about data modelling.
Related
I've really been scratching my head over this and don't know how to ask the question well enough to find an answer on Google or StackOverflow etc.
There is a very old system used at work - I don't have access to the server side so can't view its tables, but I do know its an SQL database and have done enough experimenting with the API to see what adding to each table does, and I'm questioning how it allocates primary keys;
It has a lot of tables, each with a primary key as expected, but the primary key on any/all of its tables seems to be allocated so that there is absolutely no duplication of primary keys anywhere in the system.
e.g.
add row to table 1 get pk = 1
add row to table 2 get pk = 2
add row to table 1 again, get pk = 3
add row to table 10 and get pk = 4
Is this method some sort of old database technique?
What could be the purpose of doing this?
There are more funny nuances that I won't get into detail of, e.g. a certain range of pk's being allocated for certain tables but I just wanted to see if anyone recognises the main principle here and if there's a point to it, or if it's just bad / weird design
A primary key only needs to be unique within a single table. There is no such thing as a primary key across multiple tables.
This might be useful under some circumstances. For instance, this would allow all entities to be represented in a single table. This can be handy for "generic" information, such as adding comments to the entities.
More prosaically, I have seen this in older Oracle databases. Oracle did not have any automated mechanism for generating ids, so this required using a sequence. As a matter of convenience, laziness, or design, multiple tables might use the same sequence -- resulting in the behavior that you see.
I have been tasked with creating a database but first i have to create a design of it as an erd, i am using for this a program named toad data modeler, but i have one problem with the foreign keys and relations in general.
As seen by this picture(the database is in Polish but you should understand what i mean) :
https://i.ibb.co/Qj6r7Dk/436343664.jpg
The row id_pacjenta shows up in entity9 without a reason, i didn't create a relation between pacjenci and entity9, only entity 9 and Wizyta, Why such a behavior occurs? Also i can't delete it because it automatically deletes also the row that i need (id_wizyty) What i suppose happen is that it takes that row that i don't want (id_pacjenta) from the relationship that i made between Pacjenci and Wizyta, but i don't know why and if it should work that way, what steps should i take to fix this? Thanks a lot in advance!
There's nothing weird about it.
entity9 references wizyta and the primary key of wizyta includes a column id_pacjenta, so of course there has to be a corresponding column for wizyta.id_pacjenta in entity9, which is part of the foreign key referencing wizyta.
So the tool is correct to add both columns, when you introduce a relationship between the tables.
I have the following partial database design:
All the tables are dependent on each other so the table bvd_docflow_subdocuments is dependent on the table bdd_docflow_subsets
and the table bvd_docflow_subdocuments is dependent on bvd_docflow_subsets. So I thought I could me smart and use foreign keys on every table (and ON DELETE CASCADE). However the FK are being drilldown how further I go in to the tables.
The problem is the table bvd_docflow_documents has no point having a reference to the 1docflow_documentset_id` PK / FK. Is there a way (and maybe my design is crappy) that only the table standing above it has an FK relationship between the tables and not all the tables above it.
Edit:
More explanation:
In the bvd_docflow_subsets table information is stored about objects to create documents. There is an relation between that table and bvd_docflow_subdocuments table (This table stores master data about all the documents for an subset. (docflow_subset_id is in both tables). This is the link between those to tables.
Going further down we also got the table bvd_docflow_documents this table contains the actual document data. The link between bvd_docflow_documents and bvd_docflow_subdocuments is bvd_docflow_subdocument_id.
On every table I got an foreign key defined so when data is removed on a table all the data linked to that data is also removed.
However when we look to the bvd_docflow_documents table it has all the foreign keys from the other tables (docflow_subset_id and docflow_documentset_id) and there is the problem. The only foreign key needed for that bvd_docflow_documents table is docflow_subdocument_id and no other.
Edit 2
I have changed my design further and removed information that I don't need after initial import of the data.
See the following link for the (total) databse design:
https://sqldbm.com/Project/SQLServer/Share/_AUedvNutCEV2DGLJleUWA
The tables subsets, subdocuments and documents have a many to many relationship so I thought a table in between those 3 documents_subdocuments is the way to go were I define all the different keys for those tables.
I am not used to the database design first and then build it. But, for everything there is a first time, and I try to do make a database that is using standards and is using the power of SQL Server the correct way.
I'll address the bottom-most table and ignore the rest for the most part.
But first some comments. Your schema is simply a model of a system. To provide feedback, one must understand this "system" and how it actually works to evaluate your model. In addition, it is important to understand your entities and your reasons for choosing them and modelling them in the specified manner. Without that understanding all of this guessing based on experience.
And another comment. Slapping an identity column into every table is just lazy modelling IMO. Others will disagree, but you need to also enforce all natural keys. Do you have natural keys? It is rare not to have any. Enforce those that do exist.
And one last comment. Stop the ridiculous pattern of prepending the column names with the table names. And you should really think long and hard about using very long table names. Given what you have, I sense you need a schema for your docflow stuff.
For the documents table, your current PK makes no sense. Again, you've slapped an identity column into the table. By itself, this column is a key for the table. The inclusion of any other columns does not make the key any more "unique" - that inclusion is logical nonsense. Following your pattern, you would designate the identity column as the primary key. But ...
According to your image, the documents table is related to one and only one subdocument. You added a foreign key to that table - which matches the image. You also added additional columns and foreign keys to the "higher" tables. So now a document "points" to a specific subdocument. It also points to a specific subset - which may have no relationship to the subdocument. The same thought applies to the other FK. I have a doubt that this is logically correct. So why do these columns (and related FKs) exist? Perhaps this is the result of premature optimization - which everyone knows is the root of all evil coding. Again, it is impossible to know if this is "right" or even "useful" for your model.
To answer your question "... is there a way", the answer is obviously yes. You remove the columns of which you complain. You added them - Why? Is this perhaps a problem with the tool you are using?
And some last comments. There is nothing special about "varchar(50)". Perhaps this is a place holder that will be updated later. It may also be another sign of laziness. And generally speaking, columns with names like "type" and "code" tend to be foreign keys to "lookup" tables - because people like to add, modify, or remove these sorts categorization values over time. I'm also concerned about the column name overlap among the tables. "Location" exists in multiple tables, as do action_code and action_id. And a column named "id" (action_id) suggests a lookup to another table - is it? Should it be? Is there a relationship between action_id and action_code? From a distance it is impossible to answer any of these questions.
But designing a database is more art than science. Sometimes you just need to create something, populate it with some sample data, and then determine if it works for your needs. Everyone will get something wrong in the first try. That is expected; that is how you learn. The most difficult part is actually completing your first attempt.
I have some student data, I need to save in database. Refer pic here:
I want to generate report (Pi chart, Bar graph) using these data to show that how much understanding they keep of these subject.
What would be the the table structure like to save these data, considering there would be more than 100 students in a class.
I am using SQL database.
Your suggestion will be highly appreciated.
Have one table for your students. That will have the student name, roll number, etc, and an IDENTITY or AUTOINCREMENT column to create an INTEGER "id" column. This is a "surrogate key" that's much more Database friendly than using external identifiers (Such as Roll Number, which due to Sod's Law will sometimes be non-numeric, or contain a typo that needs changing after you've started recording the data).
Then have a similar table for Subjects.
Having the student and subject tables (sometimes known as Dimensions) separate from your data is called normalisation and is the basis of Relational Database Design.
Then you'd have a "Fact Table" to hold the "scores" for each student on each subject. It should have a key pointing to the Student table, a key pointing to the Subject table and two other columns, Theory and Numerical, in which to store your data.
You can then look at UNIQUE KEY constraints, PRIMARY KEYs, FOREIGN KEY constraints, INDEXes, etc, etc. Ideally from SQL Tutorials that are widely available on the interwebs.
If I was asked to query JOIN of more than three tables, what is the best way I go about understanding the relationship of the tables before I code. Should I use Database Diagram in SQL Server, or would I be given the necessary information? What would you recommend?
Thanks in advance for your time.
You could use the diagramming tools in SQL Server Management Studio to discover any Foreign Key relationships between those tables. It might be quicker than using the GUI to inspect each table in Design mode, and viewing its Relationships dialog.
Consider creating an ad-hoc View with those 3 tables. This will help you produce the SQL statement that you'd need. If any relationships exist on those 3 tables, you'll have the JOIN statement created for you by the tool.
Right click Views -> New View.
Pick the tables you need, click Add
all relationships are displayed in the Diagram Pane, and the SQL Pane will the SELECT statement with the required JOINS.
Depending on the convention they use for creating foreign keys, it shouldn't be to hard to find the relationships between tables.
The convention we use is
dbo.TableA(ID PK)
dbo.TableB(ID PK, TableAID FK)
dbo.TableC(ID PK, TableBID FK)
...
If they don't use any convention at all or didn't even create Foreign Key constraints, you can take that as an opportunity to educate them about the importance of conventions aka the lost time and money by not using them.