I am making a .NET website which makes uses of a database to store information. It's a practice/experimental project not related to work or uni projects.
My question is to with mapping of the ER diagram to a RelationModel and then onto writing the actual create table statements.
following is my ER:
http://img577.imageshack.us/img577/2405/climsyclipboardf.jpg
i'm confused about the part where an entity has ISA relation so it can be two things.
i know how i can for example map Business Account to Account by including all the attributes of Account into Business Account, but not sure if it makes sense when it comes to create statements.
for example, Account is either business or private account has payment of either CC or Direct Debit. How do i do this in create table statements?
For business vs. private accounts, you can make the account type an attribute of the account by implementing it in a column. Now the same thing can be said about CC and Direct Debit. It really depends on how intricate you want to make this system.
Related
I am planning to use Identity Server 4 and Asp.net Core Identity together. My website that will be talking to Identity Server 4/Asp.net Core Identity will be expecting that a company name comes back with each user.
Should I create a new customer table called Company and in the Asp User table add a column linking them together.
Or should this be a claim?
I know when I authenticated my user and they are sent back to my main site, I will have a company table and they will be linked but just not sure for the purposes of identifying them.
I feel like it should be a claim but I want to double check since I am new to all this.
In terms of using IdentityServer, technically everything is a claim. The "user" object IdentityServer returns will have all the properties mapped as claims. In that sense, it really doesn't matter which approach you go with.
However, it's generally better to keep data on your user table, if it makes sense to. Something like a foreign key relationship is especially valuable to exist at a database level, as there's more value to that than simply getting a company name.
Storing data as claims is most useful when that data is transient or not applicable to every user. Typical examples include things like third-party access tokens, such as from Facebook. Storing that on the database-level would inevitably result in denormalization of your database table, so it makes more sense to use a claim.
I am designing data base for inventory management system which is used by nearly 10 to 15 companies. This database contains nearly 25 tables.For designing database i'm planning to use shared schema architecture(ie each schema corresponding to a company and these all schemas are to be placed in a single database).
i want to know whether it is reliable to use shared schema architecture.
can any one please tell me is it correct decision to use above mentioned architecture.
Thanks in advance..
If I read your question, you are suggesting that each company has its own schema. This means two things:
If you decide to implement a basic change in the schema (ie not a change that one company requests), then you will have to implement this change in all the schemae.
You will probably have to implement different logic in your front
end program for each company.
Better you should develop one schema for the entire database; each table would have a field called 'CompanyID' which naturally would define to which company each row belongs. This field would be a foreign key to the Companies table.
I'm certainly no DBA and only a beginner when it comes to software development, so any help is appreciated. What is the most secure structure for storing the data from multiple parties in one database? For instance if three people have access to the same tables, I want to make sure that each person can only see their data. Is it best to create a unique ID for each person and store that along with the data then query based on that ID? Are there other considerations I should take into account as well?
You are on the right track, but mapping the USER ID into the table is probably not what you want, because in practice many users have access to the corporations data. In those cases you would store "CorpID" as a column, or more generically "ContextID". But yes, to limit access to data, each row should be able to convey who the data is for, either directly (the row actually contains a reference to CorpID, UserID, ContextID or the like) or it can be inferred by joining to other tables that reference the qualifier.
In practice, these rules are enforced by a middle tier that queries the database, providing the user context in some way so that only the correct records are selected out of the database and ultimately presented to the user.
...three people have access to the same tables...
If these persons can query the tables directly through some query tool like toad then we have a serious problem. if not, that is like they access through some middle tier/service layer or so then #wagregg's solution above holds.
coming to the case when they have direct access rights then one approach is:
create database level user accounts for each of the users.
have another table with row level grant information. say your_table has a primary key column MY_PK_COL then the structure of the GRANTS_TABLE table would be like {USER_ID; MY_PK_COL} with MY_PK_COL a foreign key to your_table.
Remove all privileges of concerned users from your_table
Create a view. SELECT * FROM your_table WHERE user_id=getCurrentUserID();
give your users SELECT/INSERT/UPDATE rights on this view.
Most of the database systems (MySQL, Oracle, SQLServer) provide way to get current logged user. (the one used in the connection string). They also provide ways to restrict access to certain tables. now for your users the view will behave as a normal table. they will never know the difference.
a problem happens when there are too many users. provisioning a database level uer account to every one of them may turn difficult. but then DBMS like MsSQLServer can use windows authentication, there by reducing the user/creation problem.
In most of the scenarios the filter at middle tier approach is the best way. but there are times when security is paramount. Also a bug in the middle tier may allow malicious users to bypass the security. SQL injection is one thing to name. then you have to do what you have to do.
It sounds like you're talking about a multi-tenant architecture, but I can't tell for sure.
This SO answer has a summary of the issues, and links to an online article containing details about the trade-offs.
Background
building an online information system which user can access through any computer. I don't want to replicate DB and code for every university or organization.
I just want user to hit a domain like www.example.com sign in and use it.
For second user it will also hit the same domain www.example.com sign in and use it. but the data for them are different.
Scenario
suppose a university has 200 employees, 2nd university has 150 and so on.
Qusetion
Do i need to have separate employee table for each university or is it OK to have a single table with a column that has University ID?
I assume 2nd is best but Suppose i have 20 universities or organizations and a total of thousands of employees.
What is the best approach?
This same thing is for all table? This is just to give you an example.
Thanks
The approach will depend upon the data, usage, and client requirements/restrictions.
Use an integrated model, as suggested by duffymo. This may be appropriate if each organization is part of a larger whole (i.e. all colleges are part of a state college board) and security concerns about cross-query access are minimal2. This approach has a minimal amount of separation between each organization as the same schema1 and relations are "openly" shared. It leads to a very simple model initially, but it can become very complicated (with compound FKs and correct usage of such) if needing relations for organization-specific values because it adds another dimension of data.
Implement multi-tenancy. This can be achieved with implicit filters on the relations (perhaps hidden behinds views and store procedures), different schemas, or other database-specific support. Depending upon implementation this may or may not share schema or relations even though all data may reside in the same database. With implicit isolation, some complicated keys or relationships can be hidden/eliminated. Multi-tenancy isolation also generally makes it harder/impossible to cross-query.
Silo the databases entirely. Each customer or "organization" has a separate database. This implies separate relations and schema groups. I have found this approach to to be relatively simple with automated tooling, but it does require managing multiple database. Direct cross-querying is impossible, although "linked databases" can be used if there is a need.
Even though it's not "a single DB", in our case, we had the following restrictions 1) not allowed to ever share/expose data between organizations, and 2) each organization wanted their own local database. Thus, our product ended up using a silo approach. Make sure that the approach chosen meets customer requirements.
None of these approaches will have any issue with "thousands", "hundreds of thousands", or even "millions" of records as long as the indices and queries are correctly planned. However, switching from one to another can violate many assumed constraints and so the decision should be made earlier on.
1 In this response I am using "schema" to refer to the security grouping of database objects (e.g. tables, views) and not the database model itself. The actual database model used can be common/shared, as we do even when using separate databases.
2 An integrated approach is not necessarily insecure - but it doesn't inherently have some of the built-in isolation of other designs.
I would normalize it to have UNIVERSITY and EMPLOYEE tables, with a one-to-many relationship between them.
You'll have to take care to make sure that only people associated with a given university can see their data. Role based access will be important.
This is called a multi-tenant architecture. you should read this:
http://msdn.microsoft.com/en-us/library/aa479086.aspx
I would go with Tenant Per Schema, which means copying the structure across different schemas, however, as you should keep all your SQL DDL in source control, this is very easy to script.
It's easy to screw up and "leak" information between tenants if doing it all in the same table.
Planing to create Access control system. Keeping an education institution in mind i created the Perimeter Tables like Main Gate, Zones, Building , Levels, Sections, Rooms(each table with foreign key relation).....Now i wish to create department table and employee tables, But how can i define a department to a particular perimeter. Because as the user the department can be a room or an entire building. Giving all the perimeter table foreign Key into the department table is not an apt way i guess. I also want the access to be in a path, don't want to authorized, if the user come to a Checkpoint through different point. I am newbie in database design, there might be a simple way i did not think of.. Please do help with a optimal design idea to create the above.
Thanks in advance..
Since the point of creating a hierarchy of securable locations is to manage who should have access to which locations, you are better off managing all of these locations in a single table with an involuted foreign key (self-referencing relationship).
Consider the following ERD:
Here you have security zones that can contain other security zones. People are granted access to the appropriate zones. Access to a lower level zone implies access to all of the zones that contain the lower level zone.
Using an involuted foreign key implies having to deal with hierarchical data, which can be a nuisance in SQL. To ease hierarchy navigation, I suggest using visitation numbers as I described at length in my answer to this question.
One thing to consider in any kind of access control system is minimizing the amount of data to be maintained by your security administrator. Many people will have the same access rules. For this reason, you may want to expand on the above ERD to use role based security in which groups not individuals are granted access to zones and individuals are granted access to groups. See my answer to this question on dba.se for more about role based security. If it might help, you could use a mixture of role-based and individual access rules.
Another option to consider is that your ACCESS table could include both allow and disallow flags. These could be used to allow access to a larger area while specifically forbidding access to a smaller area that is contained within. This approach could reduce the amount of data that needs to be managed for each person.